Correctifs appliqués

Tom Lane pushed:

Andrew Dunstan pushed:

Peter Eisentraut pushed:

Bruce Momjian pushed:

Robert Haas pushed:

  • Fix interaction of foreign tuple routing with remote triggers. Without these fixes, changes to the inserted tuple made by remote triggers are ignored when building local RETURNING tuples. In the core code, call ExecInitRoutingInfo at a later point from within ExecInitPartitionInfo so that the FDW callback gets invoked after the returning list has been built. But move CheckValidResultRel out of ExecInitRoutingInfo so that it can happen at an earlier stage. In postgres_fdw, refactor assorted deparsing functions to work with the RTE rather than the PlannerInfo, which saves us having to construct a fake PlannerInfo in cases where we don't have a real one. Then, we can pass down a constructed RTE that yields the correct deparse result when no real one exists. Unfortunately, this necessitates a hack that understands how the core code manages RT indexes for update tuple routing, which is ugly, but we don't have a better idea right now. Original report, analysis, and patch by Etsuro Fujita. Heavily refactored by me. Then worked over some more by Amit Langote. Discussion: http://postgr.es/m/5AD4882B.10002@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/37a3058bc7c8224d4c0d8b36176d821636a1f90e
  • Remove now-unnecessary cast. Etsuro Fujita Discussion: http://postgr.es/m/5AE99BA7.9060001@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/a365f52d58317e3b24e06564e1f6474ffa3221d4

Andres Freund pushed:

  • Improve representation of 'moved partitions' indicator on deleted tuples. Previously a tuple that has been moved to a different partition (see f16241bef7c), set the block number on the old tuple to an invalid value to indicate that fact. But the tuple offset was left untouched. That turned out to trigger a wal_consistency_checking failure as reported by Peter Geoghegan, as the offset wasn't always overwritten during WAL replay. Heikki observed that we're wasting valuable data by not putting information also in the offset. Thus set that to MovedPartitionsOffsetNumber when a tuple indicates it has moved. We continue to set the block number to MovedPartitionsBlockNumber, as that seems more likely to cause problems for code not updated to know about moved tuples. As t_ctid's offset number is now always set, this refinement also fixes the wal_consistency_checking issue. This technically is a minor disk format break, with previously created moved tuples not being recognized anymore. But since there not even has been a beta release since f16241bef7c... Reported-By: Peter Geoghegan Author: Heikki Linnakangas, Amul Sul Discussion: https://postgr.es/m/CAH2-Wzm9ty+1BX7-GMNJ=xPRg67oJTVeDNdA9LSyJJtMgRiCMA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1667148a4dd98cea28b8b53d57dbc1eece1b0b5c
  • Further -Wimplicit-fallthrough cleanup. Tom's earlier commit in 41c912cad159 didn't update a few cases that are only encountered with the non-standard --with-llvm config flag. Additionally there's also one case that appears to be a deficiency in gcc's (up to trunk as of a few days ago) detection of "fallthrough" comments - changing the placement slightly fixes that. Author: Andres Freund Discussion: https://postgr.es/m/20180502003239.wfnqu7ekz7j7imm4@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/2993435dbae5deb8d2f6c2a715690a5aef4eddb8

Heikki Linnakangas pushed:

Teodor Sigaev pushed:

  • Fix pg_dump support for pre-8.2 versions. Unify indnkeys/indnatts/indnkeyatts usage for all version of query to get index information, remove indnkeys column from query as unused. Author: Marina Polyakova Noticed by: Peter Eisentraut https://git.postgresql.org/pg/commitdiff/ac7a7e328f3e7eb89874860e554517c24dac9150
  • Add HOLD_INTERRUPTS section into FinishPreparedTransaction. If an interrupt arrives in the middle of FinishPreparedTransaction and any callback decide to call CHECK_FOR_INTERRUPTS (e.g. RemoveTwoPhaseFile can write a warning with ereport, which checks for interrupts) then it's possible to leave current GXact undeleted. Backpatch to all supported branches Stas Kelvich Discussion: ihttps://www.postgresql.org/message-id/3AD85097-A3F3-4EBA-99BD-C38EDF8D2949@postgrespro.ru https://git.postgresql.org/pg/commitdiff/8f9be261f43772ccee2eae94d971bac6557cbe6a
  • Re-think predicate locking on GIN indexes. The principle behind the locking was not very well thought-out, and not documented. Add a section in the README to explain how it's supposed to work, and change the code so that it actually works that way. This fixes two bugs: 1. If fast update was turned on concurrently, subsequent inserts to the pending list would not conflict with predicate locks that were acquired earlier, on entry pages. The included 'predicate-gin-fastupdate' test demonstrates that. To fix, make all scans acquire a predicate lock on the metapage. That lock represents a scan of the pending list, whether or not there is a pending list at the moment. Forget about the optimization to skip locking/checking for locks, when fastupdate=off. 2. If a scan finds no match, it still needs to lock the entry page. The point of predicate locks is to lock the gabs between values, whether or not there is a match. The included 'predicate-gin-nomatch' test tests that case. In addition to those two bug fixes, this removes some unnecessary locking, following the principle laid out in the README. Because all items in a posting tree have the same key value, a lock on the posting tree root is enough to cover all the items. (With a very large posting tree, it would possibly be better to lock the posting tree leaf pages instead, so that a "skip scan" with a query like "A & B", you could avoid unnecessary conflict if a new tuple is inserted with A but !B. But let's keep this simple.) Also, some spelling fixes. Author: Heikki Linnakangas with some editorization by me Review: Andrey Borodin, Alexander Korotkov Discussion: https://www.postgresql.org/message-id/0b3ad2c2-2692-62a9-3a04-5724f2af9114@iki.fi https://git.postgresql.org/pg/commitdiff/0bef1c0678d94436f80450d562a866bb6fa5e509
  • Don't truncate away non-key attributes for leftmost downlinks. nbtsort.c does not need to truncate away non-key attributes for the minimum key of the leftmost page on a level, since this is only used to build a minus infinity downlink for the level's leftmost page. Truncating away non-key attributes in advance of truncating away all attributes in _bt_sortaddtup() does not affect the correctness of CREATE INDEX, but it is misleading. Author: Peter Geoghegan Discussion: https://www.postgresql.org/message-id/CAH2-WzkAS2M3ussHG-s_Av=Zo6dPjOxyu5fNRkYnxQV+YzGQ4w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2a9e04f0a8ada12d4af4f095e4dbe164e2983bce

�lvaro Herrera pushed:

  • Don't mark pages all-visible spuriously. Dan Wood diagnosed a long-standing problem that pages containing tuples that are locked by multixacts containing live lockers may spuriously end up as candidates for getting their all-visible flag set. This has the long-term effect that multixacts remain unfrozen; this may previously pass undetected, but since commit XYZ it would be reported as "ERROR: found multixact 134100944 from before relminmxid 192042633" because when a later vacuum tries to freeze the page it detects that a multixact that should have gotten frozen, wasn't. Dan proposed a (correct) patch that simply sets a variable to its correct value, after a bogus initialization. But, per discussion, it seems better coding to avoid the bogus initializations altogether, since they could give rise to more bugs later. Therefore this fix rewrites the logic a little bit to avoid depending on the bogus initializations. This bug was part of a family introduced in 9.6 by commit a892234f830e; later, commit 38e9f90a227d fixed most of them, but this one was unnoticed. Authors: Dan Wood, Pavan Deolasee, �lvaro Herrera Reviewed-by: Masahiko Sawada, Pavan Deolasee, �lvaro Herrera Discussion: https://postgr.es/m/84EBAC55-F06D-4FBE-A3F3-8BDA093CE3E3@amazon.com https://git.postgresql.org/pg/commitdiff/d2599ecfcc74fea9fad1720a70210a740c716730

Correctifs en attente

Thomas Munro sent in a patch to avoid counting zero-filled buffers as 'read' in EXPLAIN.

Amit Langote sent in a patch to fix an issue where stats_ext test fails with -DCATCACHE_FORCE_RELEASE.

Stas Kelvich sent in a patch to implement global snapshots.

Micha�l Paquier sent in a patch to fix gaps in modules with handling of partitioned indexes.

John Naylor sent in a patch to replace the /ad hoc/ format for conversion functions.

Dmitry Dolgov sent in a patch to enable logging statistics for full-page writes.

Robert Haas sent in a patch to fix an issue which caused explain buffers to have the wrong counter with parallel plans.

Peter Eisentraut sent in a patch to PL/pgSQL to flatten TOAST data in nonatomic context.

Tom Lane sent in a patch to prevents overwriting unchanged headers.

Aleksandr Parfenov sent in a patch to optimize the use of immutable functions as relations.

Ildar Musin sent in a patch to add a MAP syntax for applying functions to arrays.

Sergei Kornilov sent in a patch to enable reloading recovery.conf during recovery.

�lvaro Herrera sent in another revision of a patch to fix a bug which resulted in VM map freeze corruption.

Takayuki Tsunakawa sent in a patch to correct some omissions from the documentation of the new table partitioning feature.

Thomas Munro sent in a patch to fix const warnings when building with --enable-dtrace.

Andrew Dunstan sent in two revisions of a patch to add some vertical whitespace to structures so that the enclosing braces etc appear on their own lines.