On Wed, 2009-02-11 at 12:20 -0500, Tom Lane wrote:
> 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.
>
I'm approaching this from the perspective of our system at Truviso. I
used the cursor example to illustrate the issue in normal postgresql,
but our problem isn't directly related to cursors.
I don't have a compelling use case right now for normal postgresql,
because of the reasons you mention. However, at Truviso, we have to come
up with some kind of solution to this anyway. Ideally, I'd like to make
something that's acceptable to postgres in general (meaning no
performance impact or code ugliness).
I could imagine some situations that this could be more useful in the
future. For instance, Hot Standby will increase the consequences of not
advancing xmin when it's possible to do so.
Regards,Jeff Davis
