aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* In pg_upgrade, issue proper error message when we can't open PG_VERSION.Bruce Momjian2012-10-10
| | | | Backpatch to 9.2.
* Fix PGXS support for building loadable modules on AIX.Tom Lane2012-10-09
| | | | | | | | | | Building a shlib on AIX requires use of the mkldexport.sh script, but we failed to install that, preventing its use from non-source-tree contexts. Also, Makefile.aix had the wrong idea about where to find the installed copy of the postgres.imp symbol file used by AIX. Per report from John Pierce. Patch all the way back, since this has been broken since the beginning of PGXS.
* Fix lo_import and lo_export to return useful error messages more often.Tom Lane2012-10-08
| | | | | | | | | I found that these functions tend to return -1 while leaving an empty error message string in the PGconn, if they suffer some kind of I/O error on the file. The reason is that lo_close, which thinks it's executed a perfectly fine SQL command, clears the errorMessage. The minimum-change workaround is to reorder operations here so that we don't fill the errorMessage until after lo_close.
* Fix lo_export usage in example programs.Tom Lane2012-10-08
| | | | lo_export returns -1, not zero, on failure.
* Say ANALYZE, not VACUUM, in error message on analyze in hot standby.Heikki Linnakangas2012-10-08
| | | | Tomonaru Katsumata
* Removed sentence about not being able to retrieve more than one row at a time,Michael Meskes2012-10-05
| | | | because it is not correct.
* Fixed test for array boundary.Michael Meskes2012-10-05
| | | | | | Instead of continuing if the next character is not an array boundary get_data() used to continue only on finding a boundary so it was not able to read any element after the first.
* Fix permissions explanations in CREATE DATABASE and CREATE SCHEMA docs.Tom Lane2012-10-04
| | | | | | | | | | These reference pages still claimed that you have to be superuser to create a database or schema owned by a different role. That was true before 8.1, but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership to any role you are a member of. However, at the time we were thinking of that primarily as a change to the ALTER OWNER rules, so the need to touch these two CREATE ref pages got missed.
* Fix typo in comment, and reword it slightly while we're at it.Heikki Linnakangas2012-10-04
|
* Avoid planner crash/Assert failure with joins to unflattened subqueries.Tom Lane2012-10-03
| | | | | | | | | | | | | | | | | | | examine_simple_variable supposed that any RTE_SUBQUERY rel it gets pointed at must have been planned already. However, this isn't a safe assumption because we must do selectivity estimation while generating indexscan paths, and that code might look at join clauses involving a rel that the loop in set_base_rel_sizes() hasn't reached yet. The simplest fix is to play dumb in such a situation, that is give up trying to extract any stats for the Var. This could possibly be improved by making a separate pass over the RTE list to plan each unflattened subquery before we start the main planning work --- but that would be pretty invasive and it doesn't seem worth it, for now at least. (We couldn't just break set_base_rel_sizes() into two loops: the prescan would need to handle all subquery rels in the query, not only those in the current join subproblem.) This bug was introduced in commit 1cb108efb0e60d87e4adec38e7636b6e8efbeb57, although I think that subsequent changes may have exposed it more than it was originally. Per bug #7580 from Maxim Boguk.
* REASSIGN OWNED: consider grants on tablespaces, tooAlvaro Herrera2012-10-03
| | | | | | | | Apparently this was considered in the original code (see commit cec3b0a9) but I failed to notice that such entries would always be skipped by the database check at the start of the loop. Per bugs #7578 by Nikolay, #6116 by tushar.qa@gmail.com.
* In pg_upgrade, use full path name for analyze_new_cluster.sh script.Bruce Momjian2012-10-02
| | | | Backpatch to 9.2.
* Work around unportable behavior of malloc(0) and realloc(NULL, 0).Tom Lane2012-10-02
| | | | | | | | | | | | | | | | On some platforms these functions return NULL, rather than the more common practice of returning a pointer to a zero-sized block of memory. Hack our various wrapper functions to hide the difference by substituting a size request of 1. This is probably not so important for the callers, who should never touch the block anyway if they asked for size 0 --- but it's important for the wrapper functions themselves, which mistakenly treated the NULL result as an out-of-memory failure. This broke at least pg_dump for the case of no user-defined aggregates, as per report from Matthew Carrington. Back-patch to 9.2 to fix the pg_dump issue. Given the lack of previous complaints, it seems likely that there is no live bug in previous releases, even though some of these functions were in place before that.
* Fix typo in previous warning-silencing patch.Heikki Linnakangas2012-10-02
| | | | Fujii Masao
* In pg_upgrade, improve error reporting when the number of relationBruce Momjian2012-10-02
| | | | | | objects does not match between the old and new clusters. Backpatch to 9.2.
* Adjust pg_upgrade query so toast tables related to system catalog schemaBruce Momjian2012-10-02
| | | | | | | | entries are not dumped. This fixes an error caused by droping/recreating the information_schema, but other failures were also possible. Backpatch to 9.2.
* In pg_upgrade, try to convert the locale names to canonical form beforeBruce Momjian2012-10-02
| | | | | | comparison; also report the old/new values if they don't match. Backpatch to 9.2.
* Silence compiler warning about pointer type mismatch on some platforms.Heikki Linnakangas2012-10-02
| | | | | | timeval.t_sec is of type time_t, which is not always compatible with long. I'm not sure if this was just harmless warning or a real bug, but this fixes it, anyway.
* Allow a few seconds for Windows to catch up with a directory rename when ↵Andrew Dunstan2012-10-02
| | | | checking pg_upgrade.
* Fix access past end of string in date parsing.Heikki Linnakangas2012-10-02
| | | | | | This affects date_in(), and a couple of other funcions that use DecodeDate(). Hitoshi Harada
* 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.
* Fix tar files emitted by pg_basebackup to be POSIX conformant.Tom Lane2012-09-28
| | | | | | | | | | | | | Back-patch portions of commit 05b555d12bc2ad0d581f48a12b45174db41dc10d. There doesn't seem to be any reason not to fix pg_basebackup fully, but we can't change pg_dump's "magic" string without breaking older versions of pg_restore. Instead, just patch pg_restore to accept either version of the magic string, in hopes of avoiding compatibility problems when 9.3 comes out. I also fixed pg_dump to write the correct 2-block EOF marker, since that won't create a compatibility problem with pg_restore and it could help with some versions of tar. Brian Weaver and Tom Lane
* 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
* Fix examples of how to use "su" while starting the server.Tom Lane2012-09-25
| | | | | | | | The syntax "su -c 'command' username" is not accepted by all versions of su, for example not OpenBSD's. More portable is "su username -c 'command'". So change runtime.sgml to recommend that syntax. Also, add a -D switch to the OpenBSD example script, for consistency with other examples. Per Denis Lapshin and Gábor Hidvégi.
* Prevent emitting "ALTER VIEW foo SET ()".Tom Lane2012-09-24
| | | | | Small oversight in commit 0f524ea0cf388a149f362e48a33c01662eeddc04 ... per report from Grazvydas Valeika.
* Stamp 9.2.1.REL9_2_1Tom Lane2012-09-19
|
* Update release notes for 9.2.1, 9.1.6, 9.0.10, 8.4.14, 8.3.21.Tom Lane2012-09-19
|
* 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.
* Translation updatesPeter Eisentraut2012-09-19
|
* pg_upgrade: Remove check for pg_configPeter Eisentraut2012-09-18
| | | | | | It is no longer used, but was still being checked for. bug #7548 from Reinhard Max
* 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.
* Provide adequate documentation of the "table_name *" notation.Tom Lane2012-09-17
| | | | | | | | | Somewhere along the line, somebody decided to remove all trace of this notation from the documentation text. It was still in the command syntax synopses, or at least some of them, but with no indication what it meant. This will not do, as evidenced by the confusion apparent in bug #7543; even if the notation is now unnecessary, people will find it in legacy SQL code and need to know what it does.
* 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.
* Fix documentation reference to maximum allowed for autovacuum_freeze_max_age.Kevin Grittner2012-09-16
| | | | | | | | | The documentation mentioned setting autovacuum_freeze_max_age to "its maximum allowed value of a little less than two billion". This led to a post asking about the exact maximum allowed value, which is precisely two billion, not "a little less". Based on question by Radovan Jablonovsky. Backpatch to 8.3.
* Back-patch fix and test case for bug #7516.Tom Lane2012-09-14
| | | | | | | | | | | | | | Back-patch commits 9afc6481117d2dd936e752da0424a2b6b05f6459 and b8fbbcf37f22c5e8361da939ad0fc4be18a34ca9. The first of these is really a minor code cleanup to save a few cycles, but it turns out to provide a workaround for the misoptimization problem described in bug #7516. The second commit adds a regression test case. Back-patch the fix to all active branches. The test case only works as far back as 9.0, because it relies on plpgsql which isn't installed by default before that. (I didn't have success modifying it into an all-plperl form that still provoked a crash, though this may just reflect my lack of Perl-fu.)
* 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.
* 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 catalog docs to reflect connoinherit change in 09ff76f.Andrew Dunstan2012-09-12
| | | | Backpatch to 9.2.
* Fix typo: lexemes misspelled in full text search docs.Kevin Grittner2012-09-12
| | | | | | | Dan Scott Backpatch original commit 4bc0d2e2cfa8ac523524dccf6f849989c6739083 to 9.1
* 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.
* Adjust PL/Python regression tests some more for Python 3.3.Tom Lane2012-09-08
| | | | | | | | | | | Commit 2cfb1c6f77734db81b6e74bcae630f93b94f69be fixed some issues caused by Python 3.3 choosing to iterate through dict entries in a different order than before. But here's another one: the test cases adjusted here made two bad entries in a dict and expected the one complained of would always be the same. Possibly this should be back-patched further than 9.2, but there seems little point unless the earlier fix is too.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 14:22:20 +0000