Re: PATCH to allow concurrent VACUUMs to not lock each

On P, 2005-07-03 at 12:19 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)net> writes:
> > Ok, this is a new version of the vacuum patch with the following changes
> > following some suggestions in this thread.
>
> The more I look at this, the uglier it looks ... and I still haven't
> seen any convincing demonstration that it *works*, ie doesn't have
> bad side-effects on the transaction-is-in-progress logic.

The function GetOldestXmin is used *only* when determining oldest xmin
for transactions.

> I'm particularly concerned about what happens to the RecentXmin horizon
> for pg_subtrans and pg_multixact operations.

How are they affected by this change ? They should still see the vacuum
as oldest transaction, unless they

Oh, now I see. I'm pretty sure that at the time of original patch, the
*only* uses of GetOldestXmin was from VACUUM and catalog/index.c and
both for the same purpose, but now I see also a call from
access/transam/xlog.c.

Perhaps I should separate the function used by vacuum into another
function, say GetOldestDataChangingXmin(), to keep the possible impact
as localised as possible.

Do you have any specific concerns related to this patch after that ?

Or should I just back off for now and maybe start a separate project for
ironing out patches related to running postgresql in real-world 24/7
OLTP environment (similar to what Bizgres does for OLAP ) ?

--
Hannu Krosing <hannu(at)skype(dot)net>