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
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 |
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 |