Skip site navigation (1) Skip section navigation (2)

Re: SSI SLRU strategy choices

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI SLRU strategy choices
Date: 2010-12-28 23:33:09
Message-ID: 4D1A73B5.6000308@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-12-29 00:24:57
Subject: Re: pg_dump --split patch
Previous:From: Joel JacobsonDate: 2010-12-28 23:24:37
Subject: Re: pg_dump --split patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group