Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> 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 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services