2011/5/31 Andres Freund <andres@anarazel.de>:
> On Tuesday, May 31, 2011 03:27:22 Alvaro Herrera wrote:
>> Excerpts from Andres Freund's message of lun may 30 20:47:49 -0400 2011:
>> > On Tuesday, May 31, 2011 02:35:58 AM Andres Freund wrote:
>> > > On Tuesday, May 31, 2011 02:14:00 AM Andres Freund wrote:
>> > > > On Tuesday, May 31, 2011 01:56:05 AM C=E9dric Villemain wrote:
>> > > > > I remove my own explanations as we conclude on the same thing.
>> > > > > Attached is the fix by adding a (!reindex) =A0in the index.c if(=
).
>> > > >
>> > > > Thats imo wrong because it will break a plain REINDEX?
>> > >
>> > > > I think one possible correct fix would be the attached:
>> > > My version was wrong as well because it =A0did not observe
>> > > RelationTruncate's nblocks argument. That function is used to
>> > > "shorten" the relation in vacuum. So dropping the init fork there is
>> > > not a good idea.
>> > >
>> > > So I think it is the simpler version of simply checking the existance
>> > > of the fork before creating is ok.
>>
>> Hmm, I wonder if what we should be doing here is observe isreindex in
>> index_build to avoid creating the init fork. =A0Doing smgr access at that
>> level seems wrong.
> isreindex doesn't contain the necessary informormation as its set doing a
> REINDEX even though a new relfilenode is created and thus the fork needs =
to be
> created.
>
> It doesn't seem terribly clean do do the !smgrexists(), I aggree with you
> there. On the other hand we are calling smgrcreate() two lines down anywa=
y. I
> personally don't realy like the placement of that piece of code very much.
> Doing it in index_build seems to be the wrong place. I don't think there
> really is a good place for it right now.
I'm open to suggestions on how to rearrange this, but I think for
right now the approach you proposed upthread (add a smgrexists() test)
is probably the simplest way to fix this.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
