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