aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Remove collations from generic ALTER testAlvaro Herrera2012-10-01
| | | | | | | | The error messages they generate are not portable enough. Also, since the only point of the alter_generic_1 expected file was to cover platforms with no collation support, it's now useless, so remove it.
* Provide some static-assertion functionality on all compilers.Tom Lane2012-09-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On reflection (especially after noticing how many buildfarm critters have __builtin_types_compatible_p but not _Static_assert), it seems like we ought to try a bit harder to make these macros do something everywhere. The initial cut at it would have been no help to code that is compiled only on platforms without _Static_assert, for instance; and in any case not all our contributors do their initial coding on the latest gcc version. Some googling about static assertions turns up quite a bit of prior art for making it work in compilers that lack _Static_assert. The method that seems closest to our needs involves defining a struct with a bit-field that has negative width if the assertion condition fails. There seems no reliable way to get the error message string to be output, but throwing a compile error with a confusing message is better than missing the problem altogether. In the same spirit, if we don't have __builtin_types_compatible_p we can at least insist that the variable have the same width as the type. This won't catch errors such as "wrong pointer type", but it's far better than nothing. In addition to changing the macro definitions, adjust a compile-time-constant Assert in contrib/hstore to use StaticAssertStmt, so we can get some buildfarm coverage on whether that macro behaves sanely or not. There's surely more places that could be converted, but this is the first one I came across.
* Add infrastructure for compile-time assertions about variable types.Tom Lane2012-09-30
| | | | | | | Currently, the macros only work with fairly recent gcc versions, but there is room to expand them to other compilers that have comparable features. Heavily revised and autoconfiscated version of a patch by Andres Freund.
* psql: Mark table headers in \drds output for translationPeter Eisentraut2012-09-29
|
* Disable _FORTIFY_SOURCE with ICCPeter Eisentraut2012-09-29
| | | | There are apparently some incompatibilities, per buildfarm.
* Fix bugs in "restore.sql" script emitted in pg_dump tar output.Tom Lane2012-09-29
| | | | | | | | | | | | | | | | | | | The tar output module did some very ugly and ultimately incorrect hacking on COPY commands to try to get them to work in the context of restoring a deconstructed tar archive. In particular, it would fail altogether for table names containing any upper-case characters, since it smashed the command string to lower-case before modifying it (and, just to add insult to injury, did that in a way that would fail in multibyte encodings). I don't see any particular value in being flexible about the case of the command keywords, since the string will just have been created by dumpTableData, so let's get rid of the whole case-folding thing. Also, it doesn't seem to meet the POLA for the script to restore data only in COPY mode, so add \i commands to make it have comparable behavior in --inserts mode. Noted while looking at the tar-output code in connection with Brian Weaver's patch.
* Add _FORTIFY_SOURCE to default compiler options for linux templatePeter Eisentraut2012-09-29
| | | | | Many distributors use this, so we might as well see the warnings as well.
* PL/Python: Remove workaround for returning booleans in Python <2.3Peter Eisentraut2012-09-29
| | | | | Since Python 2.2 is no longer supported, we can now use Py_RETURN_TRUE and Py_RETURN_FALSE instead of the old workaround.
* PL/Python: Convert oid to long/intPeter Eisentraut2012-09-29
| | | | | oid is a numeric type, so transform it to the appropriate Python numeric type like the other ones.
* Add alternative expected output for alter_genericAlvaro Herrera2012-09-29
| | | | | | | | | The original only expected file failed to consider machines without non-default collation support. Per buildfarm. Also, move the test to another parallel group; the one it was originally put in is already full according to comments in the schedule file. Per note from Tom Lane.
* Remove checks for now long outdated compilers.Andrew Dunstan2012-09-28
|
* Add alter_generic regression testAlvaro Herrera2012-09-28
| | | | | | | This makes refactoring of parts of the ALTER command safe(r) because we ensure no change in functionality. Author: KaiGai Kohei
* Fix tar files emitted by pg_dump and pg_basebackup to be POSIX conformant.Tom Lane2012-09-28
| | | | | | | | | | | | | | | | | | | | Both programs got the "magic" string wrong, causing standard-conforming tar implementations to believe the output was just legacy tar format without any POSIX extensions. This doesn't actually matter that much, especially since pg_dump failed to fill the POSIX fields anyway, but still there is little point in emitting tar format if we can't be compliant with the standard. In addition, pg_dump failed to write the EOF marker correctly (there should be 2 blocks of zeroes not just one), pg_basebackup put the numeric group ID in the wrong place, and both programs had a pretty brain-dead idea of how to compute the checksum. Fix all that and improve the comments a bit. pg_restore is modified to accept either the correct POSIX-compliant "magic" string or the previous value. This part of the change will need to be back-patched to avoid an unnecessary compatibility break when a previous version tries to read tar-format output from 9.3 pg_dump. Brian Weaver and Tom Lane
* Produce textual error messages for LDAP issues instead of numeric codesPeter Eisentraut2012-09-27
|
* Fix btmarkpos/btrestrpos to handle array keys.Tom Lane2012-09-27
| | | | | | | | This fixes another error in commit 9e8da0f75731aaa7605cf4656c21ea09e84d2eb1. I neglected to make the mark/restore functionality save and restore the current set of array key values, which led to strange behavior if an IndexScan with ScalarArrayOpExpr quals was used as the inner side of a mergejoin. Per bug #7570 from Melese Tesfaye.
* Have pg_terminate/cancel_backend not ERROR on non-existent processesAlvaro Herrera2012-09-27
| | | | | | | | | | | | | | | | | | This worked fine for superusers, but not for ordinary users trying to cancel their own processes. Tweak the order the checks are done in so that we correctly return SIGNAL_BACKEND_ERROR (which current callers know to ignore without erroring out) so that an ordinary user can loop through a resultset without fearing that a process might exit in the middle of said looping -- causing the remaining processes to go unsignalled. Incidentally, the last in-core caller of IsBackendPid() is now gone. However, the function is exported and must remain in place, because there are plenty of callers in external modules. Author: Josh Kupershmidt Reviewed by Noah Misch
* Run check_keywords.pl anytime gram.c is rebuilt.Tom Lane2012-09-26
| | | | | | | | | | | This script is a bit slow, but still it only takes a fraction of the time the bison run does, so the overhead doesn't seem intolerable. And we definitely need some mechanical aid here, because people keep missing the need to add new keywords to the appropriate keyword-list production. While at it, I moved check_keywords.pl from src/tools into src/backend/parser where it's actually used, and did some very minor cleanup on the script.
* Make plpgsql's unreserved keywords more unreserved.Tom Lane2012-09-26
| | | | | | | | | | | There were assorted places where unreserved keywords were not treated the same as T_WORD (that is, a random unrecognized identifier). Fix them. It might not always be possible to allow this, but it is in all these places, so I don't see any downside. Per gripe from Jim Wilson. Arguably this is a bug fix, but given the lack of other complaints and the ease of working around it (just quote the word), I won't risk back-patching.
* Add new EVENT keyword to unreserved_keyword production.Tom Lane2012-09-26
| | | | | | Once again, somebody who ought to know better forgot this. We really need some automated cross-check on the keyword-list productions, I think. Per report from Brian Weaver.
* Add support for include_dir in config file.Heikki Linnakangas2012-09-24
| | | | | | | This allows easily splitting configuration into many files, deployed in a directory. Magnus Hagander, Greg Smith, Selena Deckelmann, reviewed by Noah Misch.
* Prevent emitting "ALTER VIEW foo SET ()".Tom Lane2012-09-24
| | | | | Small oversight in commit 0f524ea0cf388a149f362e48a33c01662eeddc04 ... per report from Grazvydas Valeika.
* RELEASE_NOTES: Fix typoAlvaro Herrera2012-09-23
| | | | Jan Urbański
* Update translation updates instructionsPeter Eisentraut2012-09-22
|
* Minor corrections for ALTER TYPE ADD VALUE IF NOT EXISTS patch.Tom Lane2012-09-22
| | | | | | | | | Produce a NOTICE when the label already exists, for consistency with other CREATE IF NOT EXISTS commands. Also, fix the code so it produces something more user-friendly than an index violation when the label already exists. This not incidentally enables making a regression test that the previous patch didn't make for fear of exposing an unpredictable OID in the results. Also some wordsmithing on the documentation.
* Allow IF NOT EXISTS when add a new enum label.Andrew Dunstan2012-09-22
| | | | | | | | If the label is already in the enum the statement becomes a no-op. This will reduce the pain that comes from our not allowing this operation inside a transaction block. Andrew Dunstan, reviewed by Tom Lane and Magnus Hagander.
* Improve ruleutils.c's heuristics for dealing with rangetable aliases.Tom Lane2012-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous scheme had bugs in some corner cases involving tables that had been renamed since a view was made. This could result in dumped views that failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd Albin, as well as in some pgsql-hackers discussion back in January. Also, its behavior for printing EXPLAIN plans was sometimes confusing because of willingness to use the same alias for multiple RTEs (it was Ashutosh Bapat's complaint about that aspect that started the January thread). To fix, ensure that each RTE in the query has a unique unqualified alias, by modifying the alias if necessary (we add "_" and digits as needed to create a non-conflicting name). Then we can just print its variables with that alias, avoiding the confusing and bug-prone scheme of sometimes schema-qualifying variable names. In EXPLAIN, it proves to be expedient to take the further step of only assigning such aliases to RTEs that are actually referenced in the query, since the planner has a habit of generating extra RTEs with the same alias in situations such as inheritance-tree expansion. Although this fixes a bug of very long standing, I'm hesitant to back-patch such a noticeable behavioral change. My experiments while creating a regression test convinced me that actually incorrect output (as opposed to confusing output) occurs only in very narrow cases, which is backed up by the lack of previous complaints from the field. So we may be better off living with it in released branches; and in any case it'd be smart to let this ripen awhile in HEAD before we consider back-patching it.
* Parse pg_ident.conf when it's loaded, keeping it in memory in parsed format.Heikki Linnakangas2012-09-21
| | | | | | | | | | | | | | | | | | | | Similar changes were done to pg_hba.conf earlier already, this commit makes pg_ident.conf to behave the same as pg_hba.conf. This has two user-visible effects. First, if pg_ident.conf contains multiple errors, the whole file is parsed at postmaster startup time and all the errors are immediately reported. Before this patch, the file was parsed and the errors were reported only when someone tries to connect using an authentication method that uses the file, and the parsing stopped on first error. Second, if you SIGHUP to reload the config files, and the new pg_ident.conf file contains an error, the error is logged but the old file stays in effect. Also, regular expressions in pg_ident.conf are now compiled only once when the file is loaded, rather than every time the a user is authenticated. That should speed up authentication if you have a lot of regexps in the file. Amit Kapila
* Fix obsolete comment.Heikki Linnakangas2012-09-21
| | | | | load_hba and load_ident load stuff in a separate memory context nowadays, not in the current memory context.
* Remove execdesc.h inclusion from tcopprot.hAlvaro Herrera2012-09-20
|
* Put back AcceptInvalidationMessages calls in heap_openrv(_extended).Tom Lane2012-09-19
| | | | | | | | | | | | | | | | | | These calls were removed in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7 as part of a general refactoring and improvement of DDL locking. However, there's a problem not solved by the rewrite, which is that GRANT/REVOKE update pg_class.relacl without taking any particular lock on the target table as such. If another backend fails to do AcceptInvalidationMessages, it won't notice a recently-committed change in ACLs. Bug #7557 from Piotr Czachur demonstrates that there's at least one code path in 9.2.0 in which a command fails to do any AcceptInvalidationMessages calls at all, if the current transaction already holds all the locks it will need. Since we're hard up against the release deadline for 9.2.1, fix this by putting back the AcceptInvalidationMessages calls in heap_openrv and heap_openrv_extended, thereby restoring the historical behavior in this area. We ought to look for a more elegant and perhaps more bulletproof solution, but there's no time for that right now.
* Update time zone data files to tzdata release 2012f.Tom Lane2012-09-19
| | | | DST law changes in Fiji.
* Fix planning of btree index scans using ScalarArrayOpExpr quals.Tom Lane2012-09-18
| | | | | | | | | | | | In commit 9e8da0f75731aaa7605cf4656c21ea09e84d2eb1, I improved btree to handle ScalarArrayOpExpr quals natively, so that constructs like "indexedcol IN (list)" could be supported by index-only scans. Using such a qual results in multiple scans of the index, under-the-hood. I went to some lengths to ensure that this still produces rows in index order ... but I failed to recognize that if a higher-order index column is lacking an equality constraint, rescans can produce out-of-order data from that column. Tweak the planner to not expect sorted output in that case. Per trouble report from Robert McGehee.
* Fix array_typanalyze to work for domains over arrays.Tom Lane2012-09-18
| | | | | Not sure how we missed this case, but we did. Per bug #7551 from Diego de Lima.
* libpq: Add missing directory to installdirs targetPeter Eisentraut2012-09-17
| | | | It prevented the libpq directory from being installable by itself.
* PL/Python: Improve Python 3 regression test setupPeter Eisentraut2012-09-16
| | | | | | | | | | | | | Currently, we are making mangled copies of plpython/{expected,sql} to plpython/python3/{expected,sql}, and run the tests in plpython/python3. This has the disadvantage that the regression.diffs file, if any, ends up in plpython/python3, which is not the normal location. If we instead make the mangled copies in plpython/{expected,sql}/python3/, we can run the tests from the normal directory, regression.diffs ends up the normal place, and the pg_regress invocation also becomes a lot simpler. It's also more obvious at run time what's going on, because the tests end up being named "python3/something" in the test output.
* Rethink heuristics for choosing index quals for parameterized paths.Tom Lane2012-09-16
| | | | | | | | | | | | | | | | | | | | | | Some experimentation with examples similar to bug #7539 has convinced me that indxpath.c's original implementation of parameterized-path generation was several bricks shy of a load. In general, if we are relying on a particular outer rel or set of outer rels for a parameterized path, the path should use every indexable join clause that's available from that rel or rels. Any join clauses that get left out of the indexqual will end up getting applied as plain filter quals (qpquals), and that's generally a significant loser compared to having the index AM enforce them. (This is particularly true with btree, which can skip the index scan entirely if it can see that the given indexquals are mutually contradictory.) The original heuristics failed to ensure this, though, and were overly complicated anyway. Rewrite to make the code explicitly identify each useful set of outer rels and then select all applicable join clauses for each one. The one plan that changes in the regression tests is in fact for the better according to the planner's cost estimates. (Note: this is not a correctness issue but just a matter of plan quality. I don't yet know what is going on in bug #7539, but I don't expect this change to fix that.)
* Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint.Simon Riggs2012-09-16
| | | | | | | | | Recovery code documents clearly that a shutdown checkpoint is executed at end of recovery - a shutdown checkpoint WAL record is written but the buffer manager had been altered to treat end of recovery as a normal checkpoint. This bug exacerbates the bufmgr relpersistence bug. Bug spotted by Andres Freund, patch by me.
* Adjust largeobject_1.source per buildfarm.Tom Lane2012-09-15
| | | | | | Looks like the correct size of DOS-ified tenk.data is 680800 not 680801. (I got the latter from a version of unix2dos that appends a trailing ^Z, which evidently is not git's practice.)
* psql: Add more constraint completionPeter Eisentraut2012-09-14
| | | | | | | - ALTER DOMAIN ... DROP/RENAME/VALIDATE CONSTRAINT - ALTER TABLE ... RENAME/VALIDATE CONSTRAINT - COMMENT ON CONSTRAINT - SET CONSTRAINTS
* Improve largeobject regression test to show size of object read from file.Tom Lane2012-09-14
| | | | | | | | | | | The idea here is to provide a more easily diagnosable failure diff when the problem is that tenk.data has been DOS-ified, as I believe to be happening currently on buildfarm member hamerkop. Per suggestion from Magnus Hagander. Also, sync output/largeobject_1.source with current regression test. Failure to do that in commit 3a0e4d36ebd7f477822d5bae41ba121a40d22ccc turns out to be the real reason that hamerkop has been complaining.
* Add a regression test case based on bug #7516.Tom Lane2012-09-14
| | | | | | Given what we now know about the cause of this bug, it seems like it'd be a real good idea to include it in the plperl regression tests, so as to catch any platform-specific cases where the code gets misoptimized.
* Properly set relpersistence for fake relcache entries.Robert Haas2012-09-14
| | | | | | | This can result in buffers failing to be properly flushed at checkpoint time, leading to data loss. Report, diagnosis, and patch by Jeff Davis.
* Keep plperl's current_call_data record on the stack, instead of palloc'ing.Tom Lane2012-09-13
| | | | | | This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
* Fix case of window function + aggregate + GROUP BY expression.Tom Lane2012-09-13
| | | | | | | | | | | | | | | | In commit 1bc16a946008a7cbb33a9a06a7c6765a807d7f59 I added a minor optimization to drop the component variables of a GROUP BY expression from the target list computed at the aggregation level of a query, if those Vars weren't referenced elsewhere in the tlist. However, I overlooked that the window-function planning code would deconstruct such expressions and thus need to have access to their component variables. Fix it to not do that. While at it, I removed the distinction between volatile and nonvolatile window partition/order expressions: the code now computes all of them at the aggregation level. This saves a relatively expensive check for volatility, and it's unclear that the resulting plan isn't better anyway. Per bug #7535 from Louis-David Mitterrand. Back-patch to 9.2.
* Fix typo in comment for pclose_check() function.Kevin Grittner2012-09-12
| | | | | | Backpatch to 9.2. Etsuro Fujit
* Fix a couple other leftover uses of 'conisonly' terminology.Tom Lane2012-09-12
|
* Fix logical errors in tsquery selectivity estimation for prefix queries.Tom Lane2012-09-11
| | | | | | | | | | | | | | | | | | | | | | I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654, stemming mostly from failure to think about the available frequency data as being element frequencies not value frequencies (so that occurrences of different elements are not mutually exclusive). This led to sillinesses such as estimating that "word" would match more rows than "word:*". The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also seems pretty ill-considered in hindsight, as it would frequently result in an estimate much larger than the available data suggests. We do need some sort of clamp, since a pattern not matching any of the MCELEMs probably still needs a selectivity estimate of more than zero. I chose instead to clamp to at least what a non-MCELEM word would be estimated as, preserving the property that "word:*" doesn't get an estimate less than plain "word", whether or not the word appears in MCELEM. Per investigation of a gripe from Bill Martin, though I suspect that his example case actually isn't even reaching the erroneous code. Back-patch to 9.1 where this code was introduced.
* Add vcregress.pl target for checking pg_upgrade.Andrew Dunstan2012-09-10
| | | | | | This follows recent addition of Windows/Mingw testing. Backpatch to Release 9.2 so we can get some buildfarm testing going.
* Make plperl safe against functions that are redefined while running.Tom Lane2012-09-09
| | | | | | | | | | | | | | | | | | validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
* Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug.Tom Lane2012-09-09
| | | | | | | | | | | | | | | Investigation shows that some intermittent build failures in ecpg are the result of a gmake bug that was reported quite some time ago: http://savannah.gnu.org/bugs/?30653 Preventing parallel builds of the ecpg subdirectories seems to dodge the bug. Per yesterday's pgsql-hackers discussion, there are some other things in the subdirectory makefiles that seem rather unsafe for parallel builds too, but there's little point in fixing them as long as we have to work around a make bug. Back-patch to 9.1; parallel builds weren't very well supported before that anyway.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-30 23:15:25 +0000