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
>> > 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
>> > of members.  Isn't that buggy? Consider what happens if we have
>> > 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
>> > 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
>of properly checking against age limit.

Right. That, or a member xid below relminxid. I think both scenarios are 

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:

Reply via email to