Re: SSI SLRU strategy choices

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