Re: nested xacts and phantom Xids

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>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Subject: Re: nested xacts and phantom Xids
Date: 2004-06-21 02:12:27
Message-ID: 200406210212.i5L2CRU08402@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > What ideas do you have to help him?
>
> Eat the four-byte overhead.
>
> Quite frankly, given the other functionality and performance issues
> he has to solve in the next ten days (see my other message just now),
> I think he'd be a fool to spend one more minute on phantom XIDs.
> Maybe for 7.6 someone will have the time to make the idea work.

Well, the problem with eating the 4-byte overhead is that it has a
performance/storage impact for all installations, not just those that
use nested transactions. You were discussing a performance impact for
nested transactions, but I assume that is an impact when some on the
server are using nested transactions and others are not, while this hit
would be for all sites, even when no one is using nested transactions.

However, given the list you just supplied, I agree Alvaro should focus
on these items and add the 4-bytes to store needed values rather than
continue to hack on phantom xids. We can certainly revisit that later,
even in 7.6, or never. We can put Manfred on it. He did the compaction
in the first place. :-)

One point is that if we want to re-add those 4 bytes, we have to get
community buy-in for it because it is a step backward for those who are
not going to use nested transactions. (I don't want to go the
compile-time switch route.)

As far as cleaning up some of the items after feature freeze, well, I
would like to avoid that, but it seems safe to do because the changes
should be very localized, and because win32 will be cleaning up things
during feature freeze too, I am sure.

However, going into feature freeze knowing a features isn't 100%
functional is something we try to avoid, so this would have to be a
special exception based on the fact that the features is very difficult,
and that Alvaro is working full-time on this. It does take us down the
slippery slope of having the release process dictated by completion of
nested transactions.

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-06-21 02:30:29 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Previous Message Gavin Sherry 2004-06-21 01:25:14 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-06-21 02:30:29 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Previous Message Gavin Sherry 2004-06-21 01:25:14 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE