Hi, On 2017-12-19 15:01:03 -0500, Robert Haas wrote: > On Tue, Dec 19, 2017 at 1:31 PM, Andres Freund <and...@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
