aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/float.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2018-05-04 15:24:44 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2018-05-04 18:24:45 -0300
commitd2599ecfcc74fea9fad1720a70210a740c716730 (patch)
treedb3170f7ac4b7981fe714197d47e9c98b4a5ec1b /src/backend/utils/adt/float.c
parent966268c7621c4bca534961440b497a3270395fc2 (diff)
downloadpostgresql-d2599ecfcc74fea9fad1720a70210a740c716730.tar.gz
postgresql-d2599ecfcc74fea9fad1720a70210a740c716730.zip
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
Diffstat (limited to 'src/backend/utils/adt/float.c')
0 files changed, 0 insertions, 0 deletions