Hello
> OK, so I pushed the patch. Thanks!
Thank you!
regards, Sergei
On 2020/11/27 12:05, Kyotaro Horiguchi wrote:
At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao
wrote in
On 2020/11/27 9:30, Kyotaro Horiguchi wrote:
At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
wrote in
On 2020/11/12 4:38, Sergei Kornilov wrote:
Hello
Anyway, for now I think tha
At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao
wrote in
>
>
> On 2020/11/27 9:30, Kyotaro Horiguchi wrote:
> > At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
> > wrote in
> >>
> >>
> >> On 2020/11/12 4:38, Sergei Kornilov wrote:
> >>> Hello
> >>>
> Anyway, for now I think that your fir
On 2020/11/27 9:30, Kyotaro Horiguchi wrote:
At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
wrote in
On 2020/11/12 4:38, Sergei Kornilov wrote:
Hello
Anyway, for now I think that your first patch would be enough, i.e.,
just change the context of restore_command to PGC_SIGHUP.
Glad to
At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
wrote in
>
>
> On 2020/11/12 4:38, Sergei Kornilov wrote:
> > Hello
> >
> >> Anyway, for now I think that your first patch would be enough, i.e.,
> >> just change the context of restore_command to PGC_SIGHUP.
> > Glad to hear. Attached a rebased
On 2020/11/12 4:38, Sergei Kornilov wrote:
Hello
Anyway, for now I think that your first patch would be enough, i.e.,
just change the context of restore_command to PGC_SIGHUP.
Glad to hear. Attached a rebased version of the original proposal.
Thanks for rebasing the patch!
This para
Hello
> Anyway, for now I think that your first patch would be enough, i.e.,
> just change the context of restore_command to PGC_SIGHUP.
Glad to hear. Attached a rebased version of the original proposal.
regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f04343
On 2020/11/07 6:36, Sergei Kornilov wrote:
Hello
I'm wondering if it's safe to allow restore_command to be emptied during
archive recovery. Even when it's emptied, archive recovery can proceed
by reading WAL files from pg_wal directory. This is the same behavior as
when restore_command is se
Hello
> Even if PITR is commanded, crash recovery can run before starting
> archive recovery if the server was not gracefully shut down.
Hmm... Still not sure how it's possible. Both readRecoverySignalFile and
validateRecoveryParameters are called early in StartupXLOG. If PITR was
commanded - w
Hello.
At Tue, 10 Nov 2020 14:13:17 +0300, Sergei Kornilov wrote in
> Hello
>
> > If someone changes restore_command to '' then reload while crash
> > recovery is running, the server stops for no valid reason.
>
> While *crash* recovery is running? It's possible only during Point-in-Time
> Re
Hello
> If someone changes restore_command to '' then reload while crash
> recovery is running, the server stops for no valid reason.
While *crash* recovery is running? It's possible only during Point-in-Time
Recovery, no?
At the beginning of validateRecoveryParameters we check
ArchiveRecoveryR
At Sat, 07 Nov 2020 00:36:33 +0300, Sergei Kornilov wrote in
> Hello
>
> > I'm wondering if it's safe to allow restore_command to be emptied during
> > archive recovery. Even when it's emptied, archive recovery can proceed
> > by reading WAL files from pg_wal directory. This is the same behavior
Hello
> I'm wondering if it's safe to allow restore_command to be emptied during
> archive recovery. Even when it's emptied, archive recovery can proceed
> by reading WAL files from pg_wal directory. This is the same behavior as
> when restore_command is set to, e.g., /bin/false.
I am always conf
On 2020/11/06 21:36, Sergei Kornilov wrote:
Hello
Currently when restore_command is not set, archive recovery fails
at the beginning. With the patch, how should we treat the case where
retore_command is reset to empty during archive recovery? We should
reject that change of restore_command?
Hello
> Currently when restore_command is not set, archive recovery fails
> at the beginning. With the patch, how should we treat the case where
> retore_command is reset to empty during archive recovery? We should
> reject that change of restore_command?
Good point. I think we should reject that
On 2020/10/28 21:02, Sergei Kornilov wrote:
Hello
Sorry for late response.
> ... but what's the corresponding hazard here, exactly? It doesn't seem
> that there's any way in which the decision one process makes affects
> the decision the other process makes. There's still a race condi
Hello
Sorry for late response.
>> > ... but what's the corresponding hazard here, exactly? It doesn't seem
>> > that there's any way in which the decision one process makes affects
>> > the decision the other process makes. There's still a race condition:
>> > it's possible for a walsender
>>
At Thu, 22 Oct 2020 01:59:07 +0300, Anastasia Lubennikova
wrote in
> On 10.08.2020 23:20, Robert Haas wrote:
> > On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier
> > wrote:
> >> Sorry for the late reply. I have been looking at that stuff again,
> >> and restore_command can be called in the conte
On 10.08.2020 23:20, Robert Haas wrote:
On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier wrote:
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
XLogRe
On Sun, Aug 9, 2020 at 1:21 AM Michael Paquier wrote:
> 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 readTimeL
On Wed, Aug 05, 2020 at 11:41:49AM -0400, Robert Haas wrote:
> On Sat, Mar 28, 2020 at 7:21 AM Sergei Kornilov 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
On Sat, Mar 28, 2020 at 7:21 AM Sergei Kornilov 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 reloadabl
Hello
I want to return to this discussion, since primary_conninfo is now PGC_SIGHUP
(and I hope will not be reverted)
> 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
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
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 r
On 07/02/2019 09:14, Sergei Kornilov wrote:
> We have some possible trouble with restore_command? As far i know it also
> only looked at by the startup process.
Probably right. I figured it would be useful to see what the outcome is
with primary_conninfo, so they can be treated similarly.
--
P
Hello
>> I think the recovery parameters
>>
>> archive_cleanup_command
>
> Only triggered by the checkpointer.
>
>> promote_trigger_file
>> recovery_end_command
>> recovery_min_apply_delay
>
> Only looked at by the startup process.
We have some possible trouble with restore_c
On 05/02/2019 04:35, Michael Paquier wrote:
> On Mon, Feb 04, 2019 at 11:58:28AM +0100, Peter Eisentraut wrote:
>> I think the recovery parameters
>>
>> archive_cleanup_command
>
> Only triggered by the checkpointer.
>
>> promote_trigger_file
>> recovery_end_command
>> recovery_mi
On Mon, Feb 04, 2019 at 11:58:28AM +0100, Peter Eisentraut wrote:
> I think the recovery parameters
>
> archive_cleanup_command
Only triggered by the checkpointer.
> promote_trigger_file
> recovery_end_command
> recovery_min_apply_delay
Only looked at by the startup process.
>
ject: [PATCH] Allow some recovery parameters to be changed with reload
Change
archive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay
from PGC_POSTMASTER to PGC_SIGHUP. This did not require any further
changes.
---
doc/src/sgml/config.sgml
30 matches
Mail list logo
