Re: Poorly thought out code in vacuum

On Fri, Jan 6, 2012 at 12:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Oh, that's brilliant.  OK, I'll go try that.

All right, that test does in fact reveal the broken-ness of the
current code, and the patch I committed upthread does seem to fix it,
so I've committed that.

After further reflection, I'm thinking that skipping the *second* heap
pass when a cleanup lock is not immediately available is safe even
during an anti-wraparound vacuum (i.e. scan_all = true), because the
only thing the second pass is doing is changing dead line pointers to
unused, and failing to do that doesn't prevent relfrozenxid
advancement: the dead line pointer doesn't contain an XID. The next
vacuum will clean it up: it'll see that there's a dead line pointer,
add that to the list of TIDs to be killed if seen during the index
vacuum (it won't be, since we got that far the first time, but vacuum
doesn't know or care), and then try again during the second heap pass
to mark that dead line pointer unused. This might be worth a code
comment, since it's not entirely obvious. At any rate, it seems that
the worst thing that happens from skipping a block during the second
pass is that we postpone reclaiming a line pointer whose tuple storage
has already been recovered, which is pretty far down in the weeds.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company