Hi, On 2020-11-25 17:03:58 -0300, Alvaro Herrera wrote: > On 2020-Nov-23, Andres Freund wrote: > > > On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote: > > > > In other words, my conclusion is that there definitely is a bug here and > > > I am going to restore the use of exclusive lock for setting the > > > statusFlags. > > > > Cool. > > Here's a patch. > > Note it also moves the computation of vacuum's Xmin (per > GetTransactionSnapshot) to *after* the bit has been set in statusFlags.
> From b813c67a4abe2127b8bd13db7e920f958db15d59 Mon Sep 17 00:00:00 2001 > From: Alvaro Herrera <alvhe...@alvh.no-ip.org> > Date: Tue, 24 Nov 2020 18:10:42 -0300 > Subject: [PATCH] Restore lock level to update statusFlags > > Reverts 27838981be9d (some comments are kept). Per discussion, it does > not seem safe to relax the lock level used for this; in order for it to > be safe, there would have to be memory barriers between the point we set > the flag and the point we set the trasaction Xid, which perhaps would > not be so bad; but there would also have to be barriers at the readers' > side, which from a performance perspective might be bad. > > Now maybe this analysis is wrong and it *is* safe for some reason, but > proof of that is not trivial. I just noticed that this commit (dcfff74fb16) didn't revert the change of lock level in ReplicationSlotRelease(). Was that intentional? Greetings, Andres Freund
