Excerpts from Tom Lane's message of mié oct 27 19:01:38 -0300 2010:
> I don't know what Simon is thinking, but I think he's nuts. There is is
> obvious extra overhead in COMMIT:
>
> /*
> * Wake up all walsenders to send WAL up to the COMMIT record
> * immediately if replication is enabled
> */
> if (max_wal_senders > 0)
> WalSndWakeup();
>
> which AFAICT is injecting multiple kernel calls into what's not only
> a hot-spot but a critical section (ie, any error -> PANIC).
Hmm, I wonder if that could be moved out of the critical section
somehow. Obviously the point here is to allow wal senders to react
before we write to clog (which is expensive by itself); but it seems
hard to wake up some other process without incurring exactly the same
cost (which is basically SetLatch) ... the only difference is that it
would be a single one instead of one per walsender.
BTW I note that there are no elog(ERROR) calls in that code path at all,
because syscall errors are ignored, so PANIC is not a concern (as the
code stands currently, at least). ISTM it would be good to have a
comment on SetLatch stating that it's used inside critical sections,
though.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support