On 06/09/10 23:10, Markus Wanner wrote:
Good. How about syscall overhead? One more write operation to the
self-pipe per signal from within the signal handler and one read to
actually clear the 'ready' state of the pipe from the waiter portion of
the code, right?

Right.

Do we plan to replace all (or most) existing internal signals with these
latches to circumvent the interruption problem? Or just the ones we need
to wait for using pg_usleep()?

At least the poll loops in bgwriter and walwriter need to be replaced if we want to fix the issue Tom mentioned earlier that the server currently wakes up periodically, waking up the CPU which wastes electricity. There's no hurry to replace other code.

For Postgres-R, I'd probably have to extend it to call select() not only
on the self-pipe, but on at least one other socket as well (to talk to
the GCS). As long as that's possible, it looks like a more portable
replacement for the pselect() variant that's currently in place there.

Yeah, that would be a straightforward extension.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to