Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers