]> granicus.if.org Git - postgresql/commit
Don't mark pages all-visible spuriously
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 4 May 2018 18:24:44 +0000 (15:24 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Fri, 4 May 2018 21:24:45 +0000 (18:24 -0300)
commitd2599ecfcc74fea9fad1720a70210a740c716730
treedb3170f7ac4b7981fe714197d47e9c98b4a5ec1b
parent966268c7621c4bca534961440b497a3270395fc2
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
src/backend/access/heap/heapam.c