Re: Improvement of procArray.xmin for VACUUM - Mailing list pgsql-patches

From Tom Lane
Subject Re: Improvement of procArray.xmin for VACUUM
Date
Msg-id 25194.1174685701@sss.pgh.pa.us
Whole thread Raw
In response to Improvement of procArray.xmin for VACUUM  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Improvement of procArray.xmin for VACUUM  (Bruce Momjian <bruce@momjian.us>)
Re: Improvement of procArray.xmin for VACUUM  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-patches
Bruce Momjian <bruce@momjian.us> writes:
> I have been thinking we could improve how quickly VACUUM can expire rows
> if we update procArray.xmin more frequently for non-SERIALIZABLE
> transactions.
> The attached patch updates procArray.xmin in this manner.

This patch is incredibly broken.  Didn't you understand what I said
about how we don't track which snapshots are still alive?  You can't
advance procArray.xmin past the xmin of the oldest live snapshot in the
backend, and you can't assume that there are no live snapshots at the
places where this patch assumes that.  (Open cursors are one obvious
counterexample, but I think there are more.)

To make intra-transaction advancing of xmin possible, we'd need to
explicitly track all of the backend's live snapshots, probably by
introducing a "snapshot cache" manager that gives out tracked refcounts
as we do for some other structures like catcache entries.  This might
have some other advantages (I think most of the current CopySnapshot
operations could be replaced by refcount increments) but it's a whole
lot more complicated and invasive than what you've got here.

            regards, tom lane

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM
Next
From: Bruce Momjian
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM