| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Allow some recovery parameters to be changed with reload |
| Date: | 2019-02-08 05:31:46 |
| Message-ID: | 20190208053146.apk5ts5ywvqrqmwv@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-02-08 09:19:31 +0900, Michael Paquier wrote:
> On Thu, Feb 07, 2019 at 11:06:27PM +0100, Peter Eisentraut wrote:
> > Probably right. I figured it would be useful to see what the outcome is
> > with primary_conninfo, so they can be treated similarly.
>
> The interactions with waiting for WAL to be available and the WAL
> receiver stresses me a bit for restore_command, as you could finish
> with the startup process switching to use restore_command with a WAL
> receiver still working behind and overwriting partially the recovered
> segment, which could lead to corruption. We should be *very* careful
> about that.
I'm not clear on the precise mechanics you're imagining here, could you
expand a bit? We kill the walreceiver when switching from receiver to
restore command, and wait for it to acknowledge that, no?
C.F. ShutdownWalRcv() call in the lastSourceFailed branch of
WaitForWALToBecomeAvailable().
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2019-02-08 06:40:39 | RE: speeding up planning with partitions |
| Previous Message | Amit Langote | 2019-02-08 05:07:28 | Re: BUG #15623: Inconsistent use of default for updatable view |