From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: alter_table regression test problem |
Date: | 2013-11-06 23:30:55 |
Message-ID: | 20131106233055.GQ14819@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-11-07 00:17:34 +0100, Andres Freund wrote:
> On 2013-11-06 17:00:40 -0300, Alvaro Herrera wrote:
> > Kevin Grittner wrote:
> >
> > > That makes for a pretty simple test for git bisect, even if
> > > everything including initdb is painfully slow with
> > > CLOBBER_CACHE_ALWAYS.
> >
> > Most likely culprit is f01d1ae3a104019d6d68aeff85c4816a275130b3
>
> Well, that test tests the functionality added in that commit, so sure,
> it can't be before that. What confuses me is that relfilenodemap has
> survived quite some CLOBBER_CACHE_ALWAYS runs in the buildfarm since:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=jaguarundi&br=HEAD
>
> Did you compile with CLOBBER_CACHE_ALWAYS or CLOBBER_CACHE_RECURSIVELY?
Either way, the code is completely and utterly broken in the face of
cache invalidations that are received when it does its internal
heap_open(RelationRelationId). I can't have been thinking straight when
I wrote the invalidation logic.
Will send a fix.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2013-11-06 23:59:37 | [PATCH 1/2] SSL: GUC option to prefer server cipher order |
Previous Message | Andres Freund | 2013-11-06 23:17:34 | Re: alter_table regression test problem |