Re: PATCH to allow concurrent VACUUMs to not lock each

On E, 2005-05-23 at 10:16 -0400, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)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.

Ok, will check out PG_TRY. I hoped that there is some way not to set
inVacuum to false at each transaction start and still be sure that it
will be reverted after vacuum_rel.

So I'll set it once at the start of connection and then maintain it in
vacuum_rel() using PG_TRY.

> 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.

Thanks, I'll get rid of them.

> 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.

There may be need to exclude vacuum/analyse on system relations from
being ignored by vacuum_rel() as I suspect that the info they both write
to pg_class, pg_attribute, and possibly other tables may be vulnerable
to crashes at right moment.

Also it may be prudent to not exclude other vacuums, when the vacuum_rel
() itself is run on a system relation.

I'm not sure which way it is, as my head gets all thick each time I try
to figure it out ;p.

I can't think of any other cases where it could matter, as at least the
work done inside vacuum_rel() itself seema non-rollbackable.

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