Re: conchuela timeouts since 2021-10-09 system upgrade - Mailing list pgsql-bugs

From Noah Misch
Subject Re: conchuela timeouts since 2021-10-09 system upgrade
Date
Msg-id 20211027030144.GA152505@rfd.leadboat.com
Whole thread Raw
In response to Re: conchuela timeouts since 2021-10-09 system upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: conchuela timeouts since 2021-10-09 system upgrade
List pgsql-bugs
On Tue, Oct 26, 2021 at 03:41:58PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Tue, Oct 26, 2021 at 02:03:54AM -0400, Tom Lane wrote:
> >> Or more
> >> practically, use advisory locks in that script to enforce that only one
> >> runs at once.
> 
> > The author did try that.
> 
> Ah, I see: if the other pgbench thread is waiting in pg_advisory_lock,
> then it is inside a transaction, so it blocks CIC from completing.
> We can get around that though, by using pg_try_advisory_lock and not
> proceeding if it fails.

Good thought.

> The attached POC does this for the 002 test;
> it looks like the same thing could be done to 003.
> 
> Now the problem with this is it will only work back to v12, because
> pgbench lacks the necessary features before that.  However, I think
> it's worth doing it like this in versions where we can do so, because
> of the load-balancing aspect: this won't waste cycles running CICs
> after the inserts have stopped, nor vice versa.
> 
> Thoughts?

I tried it out with the fix removed (git checkout fdd965d; git checkout HEAD^
src/include src/backend; git apply CIC-test-with-one-pgbench.patch).
Sensitivity (~25%) and runtime (~900ms) were in the same ballpark.  Still,
even if it doesn't buy back notable cycles, the test code seems easier to read
and understand with your change.



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17248: Installation fails...
Next
From: Tom Lane
Date:
Subject: Re: conchuela timeouts since 2021-10-09 system upgrade