On Fri, Jan 6, 2012 at 12:45 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
