On 29.12.2010 00:10, Kevin Grittner wrote:
(2) Use 8 byte SLRU entries and map the xid values over the SLRU space, with each spot allowing two different xid values. At first blush that looks good, because transaction ID wrap-around techniques mean that the two values for any one spot couldn't be active at the same time. The high bit could flag that the xid is "present" with the rest of the bits being from the commitSeqNo. The problem is that the SLRU code appears to get confused about there being wrap-around when the SLRU space is half-full, so we would get into trouble if we burned through more than 2^30 transactions during one long-running serializable read write transaction. I still like this option best, with resort to killing the long-running transaction at that point.
If you burn through more than 2^30 XIDs while a long-running transaction is still running, you have bigger problems. 2^30 is the maximum number of XIDs you can burn through before you reach XID wrap-around anyway. GetNewTransaction() will stop assigning new XIDs when you approach that limit.
(I'm not sure how you arrived at that number, though. ISTM that the slru code can handle 2^30 *pages* before getting into trouble, assuming the PagePrecedes function can handle that.)
The only issue I can see with that is that you allocate those 8 bytes for every xid, even if it's a non-serializable transaction or a subtransaction. But the overhead is probably not significant in practice.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
