Correctifs appliqués

Noah Misch pushed:

�lvaro Herrera pushed:

Tom Lane pushed:

  • Fix yet another race condition in recovery/t/001_stream_rep.pl. In commit 5c77690f6, we added polling in front of most of the get_slot_xmins calls in 001_stream_rep.pl, but today's results from buildfarm member nightjar show that at least one more poll loop is needed. Proactively add a poll loop before the next-to-last get_slot_xmins call as well. It may be that there is no race condition there because the standby_2 server is shut down at that point, but I'm quite tired of fighting with this test script. The empirical evidence that it's safe, from the buildfarm, is no stronger than the evidence for the other call that nightjar just proved unsafe. The only remaining get_slot_xmins calls without wait_slot_xmins protection are the first two, which should be OK since nothing has happened at that point. It's tempting to ignore that special case and merge get_slot_xmins and wait_slot_xmins into a single function. I didn't go that far though. Discussion: https://postgr.es/m/18436.1502228036@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/4576a69354fa2efc1bafa50df1c104c1a80c64e5
  • Fix datumSerialize infrastructure to not crash on non-varlena data. Commit 1efc7e538 did a poor job of emulating existing logic for touching Datums that might be expanded-object pointers. It didn't check for typlen being -1 first, which meant it could crash on fixed-length pass-by-ref values, and probably on cstring values as well. It also didn't use DatumGetPointer before VARATT_IS_EXTERNAL_EXPANDED, which while currently harmless is not according to documentation nor prevailing style. I also think the lack of any explanation as to why datumSerialize makes these particular nonobvious choices is pretty awful, so fix that. Per report from Jarred Ward. Back-patch to 9.6 where this code came in. Discussion: https://postgr.es/m/6F61E6D2-2F5E-4794-9479-A429BE1CEA4B@simple.com https://git.postgresql.org/pg/commitdiff/9bf4068cc321a4d44ac54089ab651a49d89bb567
  • Prevent passing down MAKELEVEL/MAKEFLAGS from non-GNU make to GNU make. 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 https://git.postgresql.org/pg/commitdiff/a76200de8462aa0551dde8132c11d648d0ad6e99
  • Fix handling of container types in find_composite_type_dependencies. 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://postgr.es/m/15268.1502309024@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/749c7c41701c62d96a56af1531e4f51e39173be3
  • Remove pgbench's restriction on placement of -M switch. Previously the -M switch had to appear before any switch that directly or indirectly specified a benchmarking script. This was both confusing and inadequately documented, as per gripe from Tatsuo Ishii. We can remove the restriction at the cost of making an extra pass over the lists of SQL commands, which seems like a cheap price (the string scans themselves likely cost much more). The change is just to not extract parameters from the SQL commands until we have finished parsing the switches and know the final value of -M. Per discussion, we'll treat this as a low-grade bug fix and sneak it into v10, rather than holding it for v11. Tom Lane, reviewed by Tatsuo Ishii and Fabien Coelho Discussion: https://postgr.es/m/20170802.110328.1963639094551443169.t-ishii@sraoss.co.jp Discussion: https://postgr.es/m/10208.1502465077@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/79681844297a9d499a10094a17e52b365afdd8bb
  • Add regression tests exercising more code paths in nodeLimit.c. Perusal of the code coverage report shows that the existing regression test cases for LIMIT/OFFSET don't exercise the nodeLimit code paths involving backwards scan, empty results, or null values of LIMIT/OFFSET. Improve the coverage. https://git.postgresql.org/pg/commitdiff/3c8de95979008d67713429d858957c5c78c23d75
  • Add regression tests exercising the non-hashed code paths in nodeSetop.c. Perusal of the code coverage report shows that the existing regression test cases for INTERSECT and EXCEPT seemingly all prefer the SETOP_HASHED implementation. Add some test cases in which we force use of the SETOP_SORTED mode. https://git.postgresql.org/pg/commitdiff/6efca23cc039b6a0b25d2ebf4a22ab7363d17fcf
  • Be more thorough about cleaning out gcov litter. At least on my machine, a run with code coverage enabled produces some ".gcov" files whose names begin with ".". "rm -f *.gcov" fails to match those, so they don't get cleaned up by "make clean". Fix it. https://git.postgresql.org/pg/commitdiff/d6ecad812f981e6ea611c1022ce7540830393a36
  • Simplify fetch-slot-xmins logic in recovery TAP tests. Merge wait_slot_xmins() into get_slot_xmins(). At this point the only place that wasn't doing a wait was the initial-state test, and a wait there seems pretty harmless. Michael Paquier Discussion: https://postgr.es/m/CAB7nPqSp_SLQb2uU7am+sn4V3g1UKv8j3yZU385oAG1cG_BN9Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3043c1ddd13cd902d820d9aea353e60ce2d3d698
  • Remove AtEOXact_CatCache(). 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 https://git.postgresql.org/pg/commitdiff/004a9702e062b5b6d61813f3fc8d71654d331d05

Peter Eisentraut pushed:

Robert Haas pushed:

Correctifs en attente

Piotr Stefaniak sent in a PoC patch to clarify the "sorry, too many clients already" error.

Mark Rofail sent in another revision of a patch to implement Foreign Key Arrays.

Masahiko Sawada sent in a patch to enable pgbench to skip creating primary keys after initialization.

Ashutosh Bapat and Thomas Munro traded patches to enable partition-wise joins between declaratively partitioned tables.

Shubham Barai sent in another revision of a patch to add predicate locking in GIN indexes.

Masahiko Sawada sent in another revision of a patch to improve the B-tree code.

Beena Emerson sent in two more revisions of a patch to add default partition support for range partitions.

Amit Kapila sent in two more revisions of a patch to parallelize queries containing initplans.

Masahiko Sawada sent in a patch to fix a typo in the login replication message.

Thomas Munro sent in another revision of a patch to log LDAP "diagnostic messages."

Thomas Munro sent in another revision of a patch to implement causal reads.

Vaishnavi Prabakaran sent in another revision of a patch to add batch/pipelining support for libpq.

Amit Khandekar sent in another revision of a patch to implement parallel append.

Micha�l Paquier sent in a patch to enable creating backup history files for backups taken from standbys.

Amit Langote sent in a patch to expand inheritance in partition bound order.

Oliver Ford sent in a patch to fix number-skipping in to_number.

Tom Lane sent in a patch to fix an issue where the PL/perl extension failed to build on Windows.

Nicolas Thauvin and Ashutosh Bapat traded patches to fix an issue where foreign tables privileges were not shown in information_schema.table_privileges.

Rushabh Lathia and Robert Haas traded patches to enable loading partitioned data through the root.

Yura Sokolov sent in another revision of a patch to make a hash table for xip in XidInMVCCSnapshot.

Micha�l Paquier sent in a patch to simplify the TAP test around replication slots.

Peter Eisentraut sent in a patch to rework and adjust how the coverage analysis tools are run.

Amit Khandekar sent in another revision of a patch to enable UPDATEs of a partition key.

Ashutosh Sharma sent in another revision of a patch to rewrite hash index scan to work page at a time, remove redundant hash function _hash_step and do some code cleanup, and improve locking startegy during VACUUM in Hash Index for regular tables.

Thomas Munro sent in another revision of a patch to enable sharing record typmods among backends.

Peter Eisentraut sent in a patch to add new contrib test suites.

Petr Jel�nek sent in a patch to allow pg_dump -j on standby when dumping from PG10+.

Dmitry Dolgov sent in another revision of a patch to enable generic type subscripting.

Alik Khilazhev sent in another revision of a patch to enable generating zipfian distributions in pgbench.

Fabien COELHO sent in another revision of a patch to enable pgbench to store select results into variables.

Marko Tiikkaja sent in another revision of a patch to enable INSTEAD OF DELETE triggers to modify the tuple for RETURNING.

Tom Lane sent in another revision of a patch to fix a bug that broke replication to Windows in PostgreSQL 10.

Tomas Vondra sent in a patch to add multivariate histograms and MCV lists.

Tomas Vondra sent in a patch to create a generational memory allocator.