Re: conchuela timeouts since 2021-10-09 system upgrade
От | Noah Misch |
---|---|
Тема | Re: conchuela timeouts since 2021-10-09 system upgrade |
Дата | |
Msg-id | 20211027030144.GA152505@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: conchuela timeouts since 2021-10-09 system upgrade (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: conchuela timeouts since 2021-10-09 system upgrade
|
Список | 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 по дате отправления: