| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Allow some recovery parameters to be changed with reload |
| Date: | 2020-08-09 05:21:49 |
| Message-ID: | 20200809052149.GB17986@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 05, 2020 at 11:41:49AM -0400, Robert Haas wrote:
> On Sat, Mar 28, 2020 at 7:21 AM Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
>> So...
>> We call restore_command only when walreceiver is stopped.
>> We use restore_command only in startup process - so we have no race condition between processes.
>> We have some issues here? Or we can just make restore_command reloadable as attached?
>
> I don't see the problem here, either. Does anyone else see a problem,
> or some reason not to press forward with this?
Sorry for the late reply. I have been looking at that stuff again,
and restore_command can be called in the context of a WAL sender
process within the page_read callback of logical decoding via
XLogReadDetermineTimeline(), as readTimeLineHistory() could look for a
timeline history file. So restore_command is not used only in the
startup process.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Asim Praveen | 2020-08-09 05:54:32 | Re: Unnecessary delay in streaming replication due to replay lag |
| Previous Message | Michael Paquier | 2020-08-09 05:00:09 | Re: 回复：how to create index concurrently on partitioned table |