Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Alternatively, you could forget about a queue per se, and just allow
>> each backend to execute the sending of its own log messages, using
>> a spinlock in shared memory to prevent concurrent issuance of log
>> messages on channels where that's a problem. That might be the
>> simplest and most robust approach.
> Hold on. Unix guarantees all write() calls are atomic, so no one gets
> in between that write.
Actually, I didn't say that I *believed* there were any channel types
where such an interlock is essential ;-). I just said that spinlocking
is a solution if the problem comes up.
Tim mentioned on-the-fly reconfiguration of logging as an area that
might need interlocking, and I'm more prepared to believe that.
Still, we seem to be getting on just fine with each backend responding
independently to reconfiguration of the pg_options values. So I'd be
inclined to build it that way, and wait for evidence of a performance
problem before spending effort to make it smarter.
Which I guess is Bruce's point also...
regards, tom lane