On 18.09.2013 22:55, Jeff Janes wrote:
> On Mon, Sep 16, 2013 at 6:59 AM, Heikki Linnakangas<hlinnakangas@vmware.com
>> wrote:
>> Here's a rebased version of the patch, including the above-mentioned
>> fixes. Nothing else new.
>
> I've applied this to 0892ecbc015930d, the last commit to which it applies
> cleanly.
>
> When I test this by repeatedly incrementing a counter in a randomly chosen
> row, then querying the whole table and comparing the results to what my
> driver knows they should be, I get discrepancies.
Ok, I found the bug. The problem was that when a HOT chain begins with a
dead tuple, when the page was frozen, the dead tuple was not removed,
but the xmin of the live tuple in the chain was replaced with FrozenXid.
That breaks the HOT-chain following code, which checks that the xmin of
the next tuple in the chain matches the xmax of the previous tuple.
I fixed that by simply not freezing a page which contains any dead
tuples. That's OK because the page will be visited by vacuum before it
becomes old enough to be "mature". However, it means that the invariant
that a page can only contain XIDs within one XID-LSN range, determined
by the LSN, is no longer true. AFAICS it everything still works, but I
would feel more comfortable if we could uphold that invariant, for
debugging reasons if nothing else. Will have to give that some more
thought..
Thanks for the testing! I just posted an updated version of the patch
elsewhere in this thread.
- Heikki