Re: PATCH to allow concurrent VACUUMs to not lock each

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: hannu(at)skype(dot)net, pgsql-patches(at)postgresql(dot)org
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Date: 2005-05-23 14:16:06
Message-ID: 7605.1116857766@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan B. 2005-05-23 14:37:18 Re: INSTEAD OF trigger on VIEWs
Previous Message Christopher Kings-Lynne 2005-05-23 14:06:53 Re: INSTEAD OF trigger on VIEWs

Browse pgsql-patches by date

  From Date Subject
Next Message Hannu Krosing 2005-05-23 15:13:47 Re: PATCH to allow concurrent VACUUMs to not lock each
Previous Message Neil Conway 2005-05-23 13:58:58 Re: PATCH to allow concurrent VACUUMs to not lock each