Alvaro Herrera <[EMAIL PROTECTED]> 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. You could probably fix that by declaring the field as
sig_atomic_t. Maybe better, just make it int.
Another problem is that if you don't take a lock then there's no memory
fence instructions executed, which would create issues around how soon
other processors would see the effects of the change. While that might
not be critical for the vacuum flags, it still seems a bit worrisome.
Given that you're only changing these flags twice per vacuum, it doesn't
seem worth taking any risks by not taking a lock ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not