Re: advance local xmin more aggressively - Mailing list pgsql-hackers

From Tom Lane
Subject Re: advance local xmin more aggressively
Date
Msg-id 11226.1234372837@sss.pgh.pa.us
Whole thread Raw
In response to Re: advance local xmin more aggressively  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: advance local xmin more aggressively
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
>> Can you clarify the circumstances in which this patch would show a
>> benefit over the current system?

> In the current code, if the process is always holding at least one
> snapshot, the process' xmin never advances.

Right, and the question is the scope of the circumstances in which
that's the case and your patch makes things better.  I believe that

* a process outside a transaction has no snapshots, so your patch
won't change anything

* a process in a serializable transaction will hold the serializable
snapshot till end of xact, so your patch won't change anything

* a process in a read-committed transaction will typically hold
snapshot(s) for the duration of each query, and then release them
all, so your patch won't change anything

You pointed out the case of opening a cursor in a read-committed
transaction, and then closing it before end of transaction, as a
place where your patch could hope to improve matters.  Are there
others?  Could your application be made to close that cursor before
opening another one (so that its set of open snapshots momentarily
goes to zero)?  It seems like the use case for more complex
bookkeeping for open snapshots is a tad narrow.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Next
From: Alvaro Herrera
Date:
Subject: Re: temporarily stop autovacuum