[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] [COMMITTERS] pgsql: Add isolationtester spec for old heapam.c bug
From:       Alvaro Herrera <alvherre () 2ndquadrant ! com>
Date:       2016-02-29 19:42:09
Message-ID: 20160229194209.GA296525 () alvherre ! pgsql
[Download RAW message or body]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]