Hi,
On 2017-12-19 15:01:03 -0500, Robert Haas wrote:
> On Tue, Dec 19, 2017 at 1:31 PM, Andres Freund <andres@anarazel.de> wrote:
> > Could I perhaps convince somebody to add that as a feature to
> > isolationtester? I'm willing to work on a bugfix for the bug itself, but
> > I've already spent tremendous amounts of time, energy and pain on
> > multixact bugs, and I'm at the moment feeling a bit unenthusiastic about
> > also working on test infrastructure for it... If somebody else is
> > willing to work on both infrastructure *and* a bugfix, that's obviously
> > even better ;)
>
> Hmm. The problem with trying to make the isolation tester do this is
> that pg_isolation_test_session_is_blocked(X, A) is documented to tell
> us whether X is waiting for one the PIDs listed in A. It's easy
> enough to tell whether X is blocked waiting for a cleanup lock by
> looking at BackendPidGetProc(pid)->wait_event_info, but that gives us
> no information about which processes are holding the buffer pins that
> prevent us from acquiring that lock. That's a hard problem to solve
> because that data is not recorded in shared memory and doing so would
> probably be prohibitively expensive.
Indeed. I kinda wonder whether we hackishly solve this by simply
returning true fore all pids if it's waiting for a cleanup lock. That's
not actually that far from the truth... The big problem with that I see
is very short waits that resolve themselves causing issues - but given
that waiting for cleanup locks is really rare, that might not be too
bad.
> <me thinks for a while>
>
> What if we add a hook to vacuum that lets you invoke some arbitrary C
> code after each block, and then write a test module that uses that
> hook to acquire and release an advisory lock at that point? Then you
> could do:
I guess that'd work, albeit a bit invasive and specific to this
test. Trying to come up with a concept that'll be generizable longer
term would be neat.
Greetings,
Andres Freund
