Re: pgsql: Add isolationtester spec for old heapam.c bug
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Add isolationtester spec for old heapam.c bug |
Дата | |
Msg-id | 20160229174405.GA282394@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgsql: Add isolationtester spec for old heapam.c bug (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Add isolationtester spec for old heapam.c bug
|
Список | pgsql-committers |
Tom Lane wrote: > I wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > >> Add isolationtester spec for old heapam.c bug > > > Hmmm .... > > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2016-02-27%2000%3A00%3A06 > > > This failure looks a lot like the timing-related problems I was chasing > > last week with deadlock-hard on the CLOBBER_CACHE_ALWAYS critters. > > spoonbill isn't CLOBBER_CACHE_ALWAYS, but it uses some weird malloc debug > > stuff that slows it down by similar orders of magnitude. You seem to need > > to think about how to make this test less timing-dependent. > > The plot thickens: > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2016-02-29%2016%3A17%3A01 > > 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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления: