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