Re: Cleaning up recovery from subtransaction start failure
От | Alvaro Herrera |
---|---|
Тема | Re: Cleaning up recovery from subtransaction start failure |
Дата | |
Msg-id | 20040914011554.GB6312@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: Cleaning up recovery from subtransaction start failure (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Cleaning up recovery from subtransaction start failure
|
Список | pgsql-hackers |
On Mon, Sep 13, 2004 at 08:40:46PM -0400, Tom Lane wrote: > The remaining calls of GetCurrentTransactionId would mostly be the ones > in heapam.c that are labeling tuples about to be written to disk. > > One minor point is that GetCurrentTransactionId would now become a > routine with a nonzero prospect of failure. 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? > Bottom line: I'm now leaning towards doing this for 8.0, since it would > make for a useful improvement in robustness, quite aside from any > performance gains from eliminating unnecessary XID assignments. I agree it's a very interesting robustness improvement. Also let me point out explicitly that it would reduce the wastage of pg_clog and pg_subtrans space by a possibly big margin, reduce the number of locks taken by XactLockTableInsert(), and reduce the recently talked about problems of transaction Id wraparound. The savings could be considerable, especially where high usage of pl/pgsql exceptions are used. 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. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) FOO MANE PADME HUM
В списке pgsql-hackers по дате отправления: