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

From Tom Lane
Subject Re: PATCH to allow concurrent VACUUMs to not lock each
Date
Msg-id 7605.1116857766@sss.pgh.pa.us
Whole thread Raw
In response to Re: PATCH to allow concurrent VACUUMs to not lock each  (Neil Conway <neilc@samurai.com>)
Responses Re: PATCH to allow concurrent VACUUMs to not lock each  (Hannu Krosing <hannu@skype.net>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> I'm a little worried about having this set to "true" after a VACUUM is
> executed, and only reset to false when the next transaction is begun: it
> shouldn't affect correctness right now, but it seems like asking for
> trouble. Resetting the flag to "false" after processing a transaction
> would probably be worth doing.

These days I'd be inclined to use a PG_TRY construct to guarantee the
flag is cleared, rather than loading another cleanup operation onto
unrelated code.

The MyProc != NULL tests are a waste of code space.  You can't even
acquire an LWLock without MyProc being set, let alone access tables.

The real issue here though is whether anyone can blow a hole in the
xmin assumptions: is there any situation where ignoring a vacuum
transaction breaks things?  I haven't had time to think about it
in any detail, but it definitely needs to be thought about.

            regards, tom lane

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Next
From: Hannu Krosing
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each