Re: alter_table regression test problem
| От | Andres Freund |
|---|---|
| Тема | Re: alter_table regression test problem |
| Дата | |
| Msg-id | 20131107095331.GA24361@awork2.anarazel.de обсуждение исходный текст |
| Ответ на | Re: alter_table regression test problem (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: alter_table regression test problem
|
| Список | pgsql-hackers |
On 2013-11-07 00:30:55 +0100, Andres Freund wrote: > 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. Ok, I've attached a fix for this, which unfortunately is not all that small. Could either of you commit it? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: