Re: Improvement of procArray.xmin for VACUUM

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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.

I updated the patch to save the MyProc->xid at the time the first cursor
is created, and not allow the MyProc->xid to be set lower than that
saved value in the current transaction. It added only a few more lines
to the patch.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +