On 2017-11-13 19:03:41 -0800, Andres Freund 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? > > Trying to write a testcase for that now.
This indeed happens, but I can't quite figure out a way to write an isolationtester test for this. The problem is that to have something reproducible one has to make vacuum block on a cleanup lock, but that currently doesn't register as waiting for the purpose of isolationtester's logic. Greetings, Andres Freund
