Peter Geoghegan wrote: > Andres Freund <and...@anarazel.de> wrote:
> > 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. He means that the tuple that heap_update moves to page 1 (which will no longer be processed by vacuum) will contain a multixact that's older than relminmxid -- because it is copied unchanged by heap_update instead of properly checking against age limit. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers