Re: Cleaning up recovery from subtransaction start failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Cleaning up recovery from subtransaction start failure
Date: 2004-09-14 01:21:41
Message-ID: 28195.1095124901@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Just to be sure I understand your proposal: the idea is that a
> subtransaction would not have a TransactionId assigned right away, but
> instead the first call to GetCurrentTransactionId in the subxact would
> assign it (and call SubTransSetParent and XactLockTableInsert). Is this
> right?

Right. The theory being that a subxact that hasn't yet done anything
to global database state need not own an XID. We had optimized on the
assumption that most subxacts would eventually need an XID, but in
hindsight I'm not sure why we thought that must be so. In any case,
I can't see any significant performance cost associated with postponing
the assignment, so why not?

> IMHO it definitely has to be in 8.0, or we risk too much in Xid
> wraparound, especially when lots of people is starting to use Pg on high
> volume, high update environments.

I'm leaning the same way. I'll work on this tomorrow unless someone
raises a good objection before then.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-14 05:48:38 Re: beta1 & beta2 & Windows & heavy load
Previous Message Alvaro Herrera 2004-09-14 01:15:54 Re: Cleaning up recovery from subtransaction start failure