Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > I'm wondering if it's safe to do something like
> > MyProc->vacuumFlags |= PROC_FOR_XID_WRAPAROUND
> > without holding the ProcArrayLock.
>
> This seems a bit itchy.
>
> One thing I'd be worried about is processors that implement that by
> fetching the whole word containing the field, setting the bit, and
> storing back the whole word. (I believe some RISC processors are likely
> to do it like that.) This would mean that it'd work OK only as long as
> no other process was concurrently changing any field that happened to be
> in the same word, which is the kind of requirement that seems horribly
> fragile.
I did it that way (i.e. added locking) and then realized that it
shouldn't really be a problem, because the only one who can be setting
vacuum flags is the process itself. Other processes can only read the
flags.
Maybe the locking is not a problem anyway, but there are two additional
flag sets in analyze and two more in the autovacuum code when it detects
that it's vacuuming a table for Xid wraparound. (The idea is to use
these flags in the deadlock patch Simon posted, so that signals are
automatically sent or not according to the current activity of
autovacuum. This way the signal handler can be kept stupid.)
Also, I forgot to mention it on the first email, but this patch adds
errcontext() lines when an autovacuum/analyze is being aborted. It
works fine, but I'm not seeing code anywhere else that does something
like this.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support