Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> Ok, here's a patch to add signaling between walreceiver and startup
> process. It indeed isn't much code, and seems pretty safe, so if no-one
> objects strongly, I'll commit.
I object --- this seems like a large change to be sticking in at this
point with no testing. I'm concerned about exactly how often the signal
will happen (ie, how much overhead is being added). I'm also concerned
about the fact that the startup process will now be receiving a constant
storm of "no-op" signals, an operational behavior that is completely
untested. If there's even one place that is failing to deal with EINTR
retry, for instance, we'll have a problem. Plus I don't care for the
platform dependency of the "fix". Being interruptable by signals is
not part of the defined API for pg_usleep.
I agree with the previous opinion that trying to get rid of that delay
is an entirely inappropriate task at this point. Leave it for 9.1.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
