Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per
Date: 2010-04-06 14:11:08
Message-ID: 19982.1270563068@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-04-06 14:53:20 pgsql: Rename "Log-streaming replication parameters" header to "Standby
Previous Message Simon Riggs 2010-04-06 13:15:53 Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-04-06 14:11:56 Re: message clarifications
Previous Message Tom Lane 2010-04-06 13:57:37 Re: message clarifications