Tom Lane wrote:
> Alvaro Herrera <> writes:
> > Tom Lane wrote:
> >> guaibasaurus is not a particularly slow machine, and it's not using any
> >> special build flags AFAICT.  So I'm not sure what to make of this case,
> >> except that it proves the timing problem can manifest on normal builds.
> > Hmm, I suppose I could fix this by using three different advisory locks
> > rather than a single one.  (My assumption is that the timing dependency
> > is the order in which the backends are awakened when the advisory lock
> > is released.)  I would release the locks one by one rather than all
> > together.
> Sounds plausible.

Pushed.  We'll see how they behave now.

> You would probably need several seconds' pg_sleep() in between the
> lock releases to ensure that even on slow/overloaded machines, there's
> enough time for all wakened backends to do what they're supposed to
> do.

I don't really like sleeps in tests, because instead of 0.01 seconds in
the normal case it now takes 10.01 seconds.  But fixing it is more
trouble than it's probably worth, so I added 5s sleeps.

If someone wants to get rid of that idle time (i.e. have a mechanism
that causes it to stop sleeping when the update is done) I would be
happy to give it a look.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to