Re: ON COMMIT temp table handling

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Mike Mascari <mascarm(at)mascari(dot)com>, swm(at)linuxworld(dot)com(dot)au
Subject: Re: ON COMMIT temp table handling
Date: 2002-11-12 04:22:40
Message-ID: 200211120422.gAC4Mei28221@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > + if ((iscommit && bstate != TBLOCK_END) ||
> > + (!iscommit && bstate != TBLOCK_ABORT))
> > + return;
>
> Why is temp table handling in need of looking into xact.c's private
> state? There is no other AtEOXact routine anywhere that does this.
> ISTM either the above code is wrong, or every other AtEOXact routine
> is wrong.
>
> There are some other things I don't like about the patch, but I can
> fix them myself. This one I thought I'd better ask about.

I looked at that. The basic issue is that Gavin wants special handling
for ON COMMIT, meaning he only wants to activate the ON COMMIT code when
the transaction is committed and it is an end block, or it is not a
commit but it is an abort.

What I don't understand is how he would get into this function unless
either is true. The two call locations would seem to be in transaction
commit/abort routines. I have to say I am confused by the various
TBLOCK values and their progression. I can't find any comments on them
and the code seems contorted.

Tom, can you guess on why they are there? I hear Gavin is traveling in
Europe for the next week or two.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Rod Taylor 2002-11-12 04:40:12 psql tab completion
Previous Message Bruce Momjian 2002-11-12 04:02:47 Re: more SGML fixes