Andres Freund <andres@anarazel.de> wrote:
>Here's that patch. I've stared at this some, and Robert did too. Robert
>mentioned that the commit message might need some polish and I'm not
>100% sure about the error message texts yet.
The commit message should probably say that the bug involves the
resurrection of previously dead tuples, which is different to there
being duplicates because a constraint is not enforced because HOT chains
are broken (that's a separate, arguably less serious problem).
>Staring at the vacuumlazy hunk I think I might have found a related bug:
>heap_update_tuple() just copies the old xmax to the new tuple's xmax if
>a multixact and still running. It does so without verifying liveliness
>of members. Isn't that buggy? Consider what happens if we have three
>blocks: 1 has free space, two is being vacuumed and is locked, three is
>full and has a tuple that's key share locked by a live tuple and is
>updated by a dead xmax from before the xmin horizon. In that case afaict
>the multi will be copied from the third page to the first one. Which is
>quite bad, because vacuum already processed it, and we'll set
>relfrozenxid accordingly. I hope I'm missing something here?
Can you be more specific about what you mean here? I think that I
understand where you're going with this, but I'm not sure.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers