Re: PATCH to allow concurrent VACUUMs to not lock each - Mailing list pgsql-patches

From Hannu Krosing
Subject Re: PATCH to allow concurrent VACUUMs to not lock each
Date
Msg-id 1124885413.4827.9.camel@fuji.krosing.net
Whole thread Raw
In response to Re: PATCH to allow concurrent VACUUMs to not lock each  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PATCH to allow concurrent VACUUMs to not lock each
Re: PATCH to allow concurrent VACUUMs to not lock each
List pgsql-patches
On K, 2005-08-17 at 15:40 -0400, Tom Lane wrote:
>                            Saatja:
> Tom Lane <tgl@sss.pgh.pa.us>
>                           Kellele:
> Bruce Momjian
> <pgman@candle.pha.pa.us>, Hannu
> Krosing <hannu@tm.ee>, Neil Conway
> <neilc@samurai.com>, pgsql-
> patches@postgresql.org
>                             Teema:
> Re: [PATCHES] PATCH to allow
> concurrent VACUUMs to not lock each
>                           Kuupäev:
> Wed, 17 Aug 2005 15:40:53 -0400
> (22:40 EEST)
>
> Just for the archives, attached is as far as I'd gotten with cleaning
> up
> Hannu's patch before I realized that it wasn't doing what it needed to
> do.  This fixes an end-of-transaction race condition (can't unset
> inVacuum before xact end, unless you want OldestXmin going backwards
> from the point of view of other people) and improves the documentation
> of what's going on.  But unless someone can convince me that it's safe
> to mess with GetSnapshotData, it's unlikely this'll ever get applied.
>
>
>

Attached is a patch, based on you last one, which messes with
GetSnapshotData in what I think is a safe way.

It introduces another attribute to PROC , proc->nonInVacuumXmin and
computes this in addition to prox->xmin inside GetSnapshotData.

When (and only when) GetOldestXmin is called with ignoreVacuum=true,
then proc->nonInVacuumXmin is checked instead of prox->xmin.

I believe that this will make this change invisible to all other places
where GetSnapshotData or GetOldestXmin is used.

--
Hannu Krosing <hannu@skype.net>






Attachment

pgsql-patches by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: PL/Perl regression tests with use_strict
Next
From: Andrew Dunstan
Date:
Subject: Re: PL/Perl regression tests with use_strict