commit : 8c894c5ff58ff41b59f1ba5c9d487aa9c3073a2f author : Tom Lane <firstname.lastname@example.org> date : Mon, 28 Aug 2017 17:24:28 -0400 committer: Tom Lane <email@example.com> date : Mon, 28 Aug 2017 17:24:28 -0400
Doc: adjust release-note credit for parallel pg_restore fix.
commit : e13c30c18095beac42e688340c8003a6ca6c9d87 author : Tom Lane <firstname.lastname@example.org> date : Mon, 28 Aug 2017 11:40:48 -0400 committer: Tom Lane <email@example.com> date : Mon, 28 Aug 2017 11:40:48 -0400
commit : dbe17366ee4367f5c2b3ecefd78db2d120d64677 author : Peter Eisentraut <firstname.lastname@example.org> date : Mon, 28 Aug 2017 10:15:52 -0400 committer: Peter Eisentraut <email@example.com> date : Mon, 28 Aug 2017 10:15:52 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: bb30ba75db8403a9ce4fb8ba6b7c3fe42ac4069e
Release notes for 9.6.5, 9.5.9, 9.4.14, 9.3.19, 9.2.23.
commit : 0601662388badc3653a86d23aaab59a9e00f0172 author : Tom Lane <firstname.lastname@example.org> date : Sun, 27 Aug 2017 17:35:04 -0400 committer: Tom Lane <email@example.com> date : Sun, 27 Aug 2017 17:35:04 -0400
Fix outdated comment
commit : 6bd9c1bc9bb4af8d79da0e9581b70c89119fbb6f author : Peter Eisentraut <firstname.lastname@example.org> date : Wed, 23 Aug 2017 14:19:35 -0400 committer: Peter Eisentraut <email@example.com> date : Wed, 23 Aug 2017 14:19:35 -0400
Author: Thomas Munro <firstname.lastname@example.org>
Fix translation marker
commit : 6bf4dca8f62c8ed222089ca729cb8ca468acfef1 author : Peter Eisentraut <email@example.com> date : Wed, 23 Aug 2017 09:56:38 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Wed, 23 Aug 2017 09:56:38 -0400
This was erroneously removed in 55a70a023c3daefca9bbd68bfbe6862af10ab479.
Backpatch introduction of TupleDescAttr(tupdesc, i).
commit : d778a77d38be8f94369f04a3813137faa6bae71b author : Andres Freund <email@example.com> date : Tue, 22 Aug 2017 07:46:05 -0700 committer: Andres Freund <firstname.lastname@example.org> date : Tue, 22 Aug 2017 07:46:05 -0700
2cd70845240 / c6293249d change the way individual attributes in a TupleDesc are stored / accessed. To reduce the effort of making extensions compatible with postgresql 11, and to ease future backpatching, backpatch introduction of TupleDescAttr() to all releases. Do not backpatch change in storage, as that'd be a breaking change for existing and working extensions. Author: Andres Freund Discussion: https://email@example.com Backpatch: 9.2-
Fix possible core dump in parallel restore when using a TOC list.
commit : 258aac0b20f6de69038568a18c3509f73dc0cffb author : Tom Lane <firstname.lastname@example.org> date : Sat, 19 Aug 2017 13:39:38 -0400 committer: Tom Lane <email@example.com> date : Sat, 19 Aug 2017 13:39:38 -0400
Commit 3eb9a5e7c unintentionally introduced an ordering dependency into restore_toc_entries_prefork(). The existing coding of reduce_dependencies() contains a check to skip moving a TOC entry to the ready_list if it wasn't initially in the pending_list. This used to suffice to prevent reduce_dependencies() from trying to move anything into the ready_list during restore_toc_entries_prefork(), because the pending_list stayed empty throughout that phase; but it no longer does. The problem doesn't manifest unless the TOC has been reordered by SortTocFromFile, which is how I missed it in testing. To fix, just add a test for ready_list == NULL, converting the call with NULL from a poor man's sanity check into an explicit command not to touch TOC items' list membership. Clarify some of the comments around this; in particular, note the primary purpose of the check for pending_list membership, which is to ensure that we can't try to restore the same item twice, in case a TOC list forces it to be restored before its dependency count goes to zero. Per report from Fabrízio de Royes Mello. Back-patch to 9.3, like the previous commit. Discussion: https://postgr.es/m/CAFcNs+pjuv0JL_x4+=71TPUPjdLHOXA4YfT32myj_OrrZb4ohA@mail.gmail.com
Further tweaks to compiler flags for PL/Perl on Windows.
commit : bff216d8789f4b7d568d2b876b0c3652f7090087 author : Tom Lane <firstname.lastname@example.org> date : Thu, 17 Aug 2017 13:13:47 -0400 committer: Tom Lane <email@example.com> date : Thu, 17 Aug 2017 13:13:47 -0400
It now emerges that we can only rely on Perl to tell us we must use -D_USE_32BIT_TIME_T if it's Perl 5.13.4 or later. For older versions, revert to our previous practice of assuming we need that symbol in all 32-bit Windows builds. This is not ideal, but inquiring into which compiler version Perl was built with seems far too fragile. In any case, we had not previously had complaints about these old Perl versions, so let's assume this is Good Enough. (It's still better than the situation ante commit 5a5c2feca, in that at least the effects are confined to PL/Perl rather than the whole PG build.) Back-patch to all supported versions, like 5a5c2feca and predecessors. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
Changed ecpg parser to allow RETURNING clauses without attached C variables.
commit : f2ed2d0a12bede8e6d91b3acc8f6100be3927990 author : Michael Meskes <firstname.lastname@example.org> date : Mon, 14 Aug 2017 11:29:34 +0200 committer: Michael Meskes <email@example.com> date : Mon, 14 Aug 2017 11:29:34 +0200
Initialize replication_slot_catalog_xmin in procarray
commit : eff9ef73f823e3e59f34b85456242fad5967a847 author : Peter Eisentraut <firstname.lastname@example.org> date : Tue, 15 Aug 2017 21:05:21 -0400 committer: Peter Eisentraut <email@example.com> date : Tue, 15 Aug 2017 21:05:21 -0400
Although not confirmed and probably rare, if the newly allocated memory is not already zero, this could possibly have caused some problems. Also reorder the initializations slightly so they match the order of the struct definition. Author: Wong, Yi Wen <firstname.lastname@example.org> Reviewed-by: Masahiko Sawada <email@example.com>
Include foreign tables in information_schema.table_privileges
commit : dbeefe64f359a938704482f4872d6db1bd93bfef author : Peter Eisentraut <firstname.lastname@example.org> date : Tue, 15 Aug 2017 19:27:22 -0400 committer: Peter Eisentraut <email@example.com> date : Tue, 15 Aug 2017 19:27:22 -0400
This appears to have been an omission in the original commit 0d692a0dc9f. All related information_schema views already include foreign tables. Reported-by: Nicolas Thauvin <firstname.lastname@example.org>
Handle elog(FATAL) during ROLLBACK more robustly.
commit : 51684bad9fece45714152f831f64e304b9dcd8ea author : Tom Lane <email@example.com> date : Mon, 14 Aug 2017 15:43:20 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 14 Aug 2017 15:43:20 -0400
Stress testing by Andreas Seltenreich disclosed longstanding problems that occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are trying to execute a ROLLBACK of an already-failed transaction. In such a case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction would skip AbortTransaction and go straight to CleanupTransaction. This led to an assert failure in an assert-enabled build (due to the ROLLBACK's portal still having a cleanup hook) or without assertions, to a FATAL exit complaining about "cannot drop active portal". The latter's not disastrous, perhaps, but it's messy enough to want to improve it. We don't really want to run all of AbortTransaction in this code path. The minimum required to clean up the open portal safely is to do AtAbort_Memory and AtAbort_Portals. It seems like a good idea to do AtAbort_Memory unconditionally, to be entirely sure that we are starting with a safe CurrentMemoryContext. That means that if the main loop in AbortOutOfAnyTransaction does nothing, we need an extra step at the bottom to restore CurrentMemoryContext = TopMemoryContext, which I chose to do by invoking AtCleanup_Memory. This'll result in calling AtCleanup_Memory twice in many of the paths through this function, but that seems harmless and reasonably inexpensive. The original motivation for the assertion in AtCleanup_Portals was that we wanted to be sure that any user-defined code executed as a consequence of the cleanup hook runs during AbortTransaction not CleanupTransaction. That still seems like a valid concern, and now that we've seen one case of the assertion firing --- which means that exactly that would have happened in a production build --- let's replace the Assert with a runtime check. If we see the cleanup hook still set, we'll emit a WARNING and just drop the hook unexecuted. This has been like this a long time, so back-patch to all supported branches. Discussion: https://email@example.com
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
commit : 1621a75531c873e48b6edd370ba70d020cbec538 author : Tom Lane <firstname.lastname@example.org> date : Mon, 14 Aug 2017 11:48:59 -0400 committer: Tom Lane <email@example.com> date : Mon, 14 Aug 2017 11:48:59 -0400
Commit 3c163a7fc's original choice to ignore all #define symbols whose names begin with underscore turns out to be too simplistic. On Windows, some Perl installations are built with -D_USE_32BIT_TIME_T, and we must absorb that or we get the wrong result for sizeof(PerlInterpreter). This effectively re-reverts commit ef58b87df, which injected that symbol in a hacky way, making it apply to all of Postgres not just PL/Perl. More significantly, it did so on *all* 32-bit Windows builds, even when the Perl build to be used did not select this option; so that it fails to work properly with some newer Perl builds. By making this change, we would be introducing an ABI break in 32-bit Windows builds; but fortunately we have not used type time_t in any exported Postgres APIs in a long time. So it should be OK, both for PL/Perl itself and for third-party extensions, if an extension library is built with a different _USE_32BIT_TIME_T setting than the core code. Patch by me, based on research by Ashutosh Sharma and Robert Haas. Back-patch to all supported branches, as commit 3c163a7fc was. Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
commit : 425be3ac900f107b8b5c2e69d404b0164f0c1c6a author : Tom Lane <firstname.lastname@example.org> date : Sun, 13 Aug 2017 16:15:14 -0400 committer: Tom Lane <email@example.com> date : Sun, 13 Aug 2017 16:15:14 -0400
The sole useful effect of this function, to check that no catcache entries have positive refcounts at transaction end, has really been obsolete since we introduced ResourceOwners in PG 8.1. We reduced the checks to assertions years ago, so that the function was a complete no-op in production builds. There have been previous discussions about removing it entirely, but consensus up to now was that it had some small value as a cross-check for bugs in the ResourceOwner logic. However, it now emerges that it's possible to trigger these assertions if you hit an assert-enabled backend with SIGTERM during a call to SearchCatCacheList, because that function temporarily increases the refcounts of entries it's intending to add to a catcache list construct. In a normal ERROR scenario, the extra refcounts are cleaned up by SearchCatCacheList's PG_CATCH block; but in a FATAL exit we do a transaction abort and exit without ever executing PG_CATCH handlers. There's a case to be made that this is a generic hazard and we should consider restructuring elog(FATAL) handling so that pending PG_CATCH handlers do get run. That's pretty scary though: it could easily create more problems than it solves. Preliminary stress testing by Andreas Seltenreich suggests that there are not many live problems of this ilk, so we rejected that idea. There are more-localized ways to fix the problem; the most principled one would be to use PG_ENSURE_ERROR_CLEANUP instead of plain PG_TRY. But adding cycles to SearchCatCacheList isn't very appealing. We could also weaken the assertions in AtEOXact_CatCache in some more or less ad-hoc way, but that just makes its raison d'etre even less compelling. In the end, the most reasonable solution seems to be to just remove AtEOXact_CatCache altogether, on the grounds that it's not worth trying to fix it. It hasn't found any bugs for us in many years. Per report from Jeevan Chalke. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAM2+6=VEE30YtRQCZX7_sCFsEpoUkFBV1gZazL70fqLn8rcvBA@mail.gmail.com
Fix handling of container types in find_composite_type_dependencies.
commit : d1c1d90e10616c5a0b4d96006ac109f27aef24af author : Tom Lane <firstname.lastname@example.org> date : Wed, 9 Aug 2017 17:03:09 -0400 committer: Tom Lane <email@example.com> date : Wed, 9 Aug 2017 17:03:09 -0400
find_composite_type_dependencies correctly found columns that are of the specified type, and columns that are of arrays of that type, but not columns that are domains or ranges over the given type, its array type, etc. The most general way to handle this seems to be to assume that any type that is directly dependent on the specified type can be treated as a container type, and processed recursively (allowing us to handle nested cases such as ranges over domains over arrays ...). Since a type's array type already has such a dependency, we can drop the existing special case for the array type. The very similar logic in get_rels_with_domain was likewise a few bricks shy of a load, as it supposed that a directly dependent type could *only* be a sub-domain. This is already wrong for ranges over domains, and it'll someday be wrong for arrays over domains. Add test cases illustrating the problems, and back-patch to all supported branches. Discussion: https://firstname.lastname@example.org
Prevent passing down MAKELEVEL/MAKEFLAGS from non-GNU make to GNU make.
commit : a784d5f215ff509a96bf70a8d98131eace0eec15 author : Tom Lane <email@example.com> date : Wed, 9 Aug 2017 12:05:53 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 9 Aug 2017 12:05:53 -0400
FreeBSD's make, for one, sets the MAKELEVEL environment variable when invoking commands. In the special Makefile we provide to hand off control from a non-GNU make to GNU make, this causes GNU make to think it is a child make invocation rather than top-level. That interferes with the hack added in commit dcae5facc to cause the temp-install tree to be made only by the top-level invocation of gmake. Unset the variable to prevent that. Likewise unset MAKEFLAGS, which FreeBSD's make also sets, and which could easily confuse gmake. There are no reports of actual trouble from that, but it seems better to be proactive. Back-patch to 9.5 where dcae5facc came in. Thomas Munro, hacked a bit more by me Discussion: https://postgr.es/m/CAEepm=1ueww35AXTkt1A3gyzZUqv5XCzh8RUNvJZAQAW=eOhVw@mail.gmail.com
Reword some unclear comments
commit : 9cc510fe89a3f013091bf7234ca893ba74a15094 author : Alvaro Herrera <email@example.com> date : Tue, 8 Aug 2017 18:46:16 -0400 committer: Alvaro Herrera <firstname.lastname@example.org> date : Tue, 8 Aug 2017 18:46:16 -0400