Re: Unlogged tables cannot be truncated twice

2011/5/31 Andres Freund <andres(at)anarazel(dot)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édric Villemain wrote:
>> > > > > I remove my own explanations as we conclude on the same thing.
>> > > > > Attached is the fix by adding a (!reindex)  in 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  did 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.  Doing 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 anyway. 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.

Robert, I wonder if all the logic with INIT_FORK is only to simulate
truncate on server restart ?
I failled to understand why not simply use truncate around the server
start (when it is in recovery).

The current large amount of code changed just to be able to flush
unlogged files on server start looks crazy, if the only point is a
possible performance impact on server restart, can't we find
something more elegant ?

While here I also wonder why GiST unlogged are not supported ?!

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support