Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> 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.
>
> > 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.
>
> I eventually realized that the problem is that his AtEOXact routine
> needs to be split in two pieces. The actual ON COMMIT DROP or DELETE
> ROWS action has to happen *before* we record transaction commit.
> (Imagine what happens if we get an error while doing that part.)
> But the cleanup of the list of on-commit objects should happen
> afterwards. I think if you look at the version I committed this
> afternoon, you'll be much happier.
Now, that makes sense.
> > 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.
>
> I think xact.c has more generality than it actually needs --- some of
> the TBLOCK states could probably be eliminated. I'm not really excited
> about rewriting it though; it works and has worked for years.
Yep, over generalized is the word for it. Let me see if I can add some
comments.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073