On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: >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.
Right. That, or a member xid below relminxid. I think both scenarios are possible. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers