From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: conchuela timeouts since 2021-10-09 system upgrade |
Date: | 2021-10-26 19:41:58 |
Message-ID: | 139687.1635277318@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Noah Misch <noah(at)leadboat(dot)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. 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?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
CIC-test-with-one-pgbench.patch | text/x-diff | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-10-26 20:36:25 | Re: BUG #17245: Index corruption involving deduplicated entries |
Previous Message | David G. Johnston | 2021-10-26 19:37:49 | Re: BUG #17246: Feature request for adoptive indexes |