Heikki Linnakangas wrote:
> We just discussed this in detail with Simon, and it looks like we have
> 5 (!) different but related problems:
Wow, four of them are mine :-(
> 2) vactuple_get_minxid doesn't take into account xmax's of tuples that
> have HEAP_XMAX_INVALID set. That's a problem:
>
> transaction 1001 - BEGIN; DELETE FROM foo where key = 1;
> transaction 1001 - ROLLBACK;
> transaction 1002 - VACUUM foo;
> crash
>
> VACUUM foo will set relminxid to 1002, because HEAP_XMAX_INVALID was set
> on the tuple (possibly by vacuum itself) that the deletion that rolled
> back touched. However, that hint-bit update hasn't hit the disk yet, so
> after recovery, the tuple will have an xmax of 1001 with no hint-bit,
> and relminxid is 1002.
>
> The simplest fix for this issue is to ignore the HEAP_XMAX_INVALID hint
> bit, and take any xmax other than InvalidXid into account when
> calculating the relminxid.
Ugh. Is there another solution to this? Say, sync the buffer so that
the hint bits are written to disk? The bug (4) below is problematic if
you take this approach; basically it removes all the optimization won by
the relminxid patch.
> Simon volunteered to make the clog changes for 3 because it's a PITR
> related issue. I can write a patch/patches for the other changes if it
> helps.
I'm swamped at the moment, so I'd appreciate it.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
