Re: New vacuum option to do only freezing
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "Bossart, Nathan" <bossartn@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-02T16:03:35Z
Lists: pgsql-hackers
Attachments
- 0001-heap_prepare_freeze_tuple-Simplify-coding.patch (text/x-diff)
On 2019-May-01, Andres Freund wrote: > Alvaro, could we perhaps clean this up a bit? This is pretty confusing > looking. I think this probably could just be changed to > > bool xmin_frozen = false; > > xid = HeapTupleHeaderGetXmin(tuple); > > if (xid == FrozenTransactionId) > xmin_frozen = true; > else if (TransactionIdIsNormal(xid)) > > or somesuch. There's no need to check for > HeapTupleHeaderXminFrozen(tuple) etc, because HeapTupleHeaderGetXmin() > already does so - and if it didn't, the issue Tom points out would be > problematic. Ah, yeah, that's simpler. I would like to introduce a couple of very minor changes to the proposed style, per the attached. * don't initialize xmin_frozen at all; rather, only set its value to the correct one when we have determined what it is. Doing premature initialization is what led to some of those old bugs, so I prefer not to do it. * Handle the BootstrapXid and InvalidXid cases explicitly, by setting xmin_frozen to true when xmin is not normal. After all, those XID values do not need any freezing. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add toast-level reloption for vacuum_index_cleanup
- ce59b75d449d 12.0 landed
-
heap_prepare_freeze_tuple: Simplify coding
- 2bf372a4ae26 12.0 landed
-
Fix missing word.
- 6665305e17ed 12.0 landed
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 landed
-
Don't mark pages all-visible spuriously
- d2599ecfcc74 11.0 cited