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