>To cover your case, what about adding the following description?
>-
>There can be delay between a promotion request by users and the trigger of
>a promotion in the server. Note that pg_wal_replay_pause() succeeds
>during that delay, i.e., until a promotion is actually triggered.
On 2020/04/08 16:41, movead...@highgo.ca wrote:
>> we should notice it in document I think.
There is the following explation about the relationship the recovery
pause and the promotion, in the document. You may want to add more
descriptions into the docs?
>--
>> we should notice it in document I think.
>There is the following explation about the relationship the recovery
>pause and the promotion, in the document. You may want to add more
>descriptions into the docs?
>--
>If a promotion is triggered while recovery is paused,
On 2020/04/02 10:41, movead...@highgo.ca wrote:
>So I'd like to propose the attached patch. The patch changes the message
logged when a promotion is requested, based on whether the recovery is
in paused state or not.
It is a compromise,
Ok, so barring any objection, I will commit the pat
>So I'd like to propose the attached patch. The patch changes the message
>logged when a promotion is requested, based on whether the recovery is
>in paused state or not.
It is a compromise, we should notice it in document I think.
Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.hi
On 2020/04/01 19:37, Fujii Masao wrote:
On 2020/04/01 18:56, movead...@highgo.ca wrote:
>This happens because the startup process detects the trigger file
after pg_wal_replay_pause() succeeds, and then make the recovery
get out of the paused state.
Yes that is.
>It might be problematic
On 2020/04/01 18:56, movead...@highgo.ca wrote:
>This happens because the startup process detects the trigger file
after pg_wal_replay_pause() succeeds, and then make the recovery
get out of the paused state.
Yes that is.
>It might be problematic to end the paused
state silently? So, to
>This happens because the startup process detects the trigger file
>after pg_wal_replay_pause() succeeds, and then make the recovery
>get out of the paused state.
Yes that is.
>It might be problematic to end the paused
>state silently? So, to make the situation less confusing, what about
>emitti
On 2020/04/01 17:58, movead...@highgo.ca wrote:
Thanks for the explanation again! Maybe I understand your point.
Great.
As far as I read the code, in the standby mode, the startup process
periodically checks the trigger file in WaitForWALToBecomeAvailable().
No?
Yes it is.
There can be s
>Thanks for the explanation again! Maybe I understand your point.
Great.
>As far as I read the code, in the standby mode, the startup process
>periodically checks the trigger file in WaitForWALToBecomeAvailable().
>No?
Yes it is.
>There can be small delay between the creation of the trigger file
On 2020/04/01 16:53, movead...@highgo.ca wrote:
But, sorry,,, I failed to understand the issue that you reported, yet
You mean that the first call of pg_wal_replay_pause() in the step #2
should check whether the trigger file exists or not? If so, could you
tell me why we should do that?
>But, sorry,,, I failed to understand the issue that you reported, yet...
>You mean that the first call of pg_wal_replay_pause() in the step #2
>should check whether the trigger file exists or not? If so, could you
>tell me why we should do that?
Sorry about my pool english. The 'pg_wal_replay_pa
On 2020/04/01 11:42, movead...@highgo.ca wrote:
When I test the patch, I find an issue: I start a stream with
'promote_trigger_file'
> GUC valid, and exec pg_wal_replay_pause() during recovery and as below it
>> shows success to pause at the first time. I think it use a initialize
>> 'S
>> When I test the patch, I find an issue: I start a stream with
>> 'promote_trigger_file'
>> GUC valid, and exec pg_wal_replay_pause() during recovery and as below it
>> shows success to pause at the first time. I think it use a initialize
>> 'SharedPromoteIsTriggered' value first time I exec th
My proposal does not change the behavior after this commit, only
changing the lines in the logs.
>>>
>>> Yes. What's your opinion about the latest patch based on Robert's idea?
>>> Barring any ojection, I'd like to commit that.
>>
>> Oh, sorry. Looks good and solves my issue
>
> Th
On 2020/03/31 19:33, Sergei Kornilov wrote:
Hello
My proposal does not change the behavior after this commit, only changing the
lines in the logs.
Yes. What's your opinion about the latest patch based on Robert's idea?
Barring any ojection, I'd like to commit that.
Oh, sorry. Looks go
Hello
>> My proposal does not change the behavior after this commit, only changing
>> the lines in the logs.
>
> Yes. What's your opinion about the latest patch based on Robert's idea?
> Barring any ojection, I'd like to commit that.
Oh, sorry. Looks good and solves my issue
regards, Sergei
On 2020/03/31 18:59, Sergei Kornilov wrote:
Hello
When I test the patch, I find an issue: I start a stream with
'promote_trigger_file'
GUC valid, and exec pg_wal_replay_pause() during recovery and as below it
shows success to pause at the first time. I think it use a initialize
'SharedPromo
Hello
> When I test the patch, I find an issue: I start a stream with
> 'promote_trigger_file'
> GUC valid, and exec pg_wal_replay_pause() during recovery and as below it
> shows success to pause at the first time. I think it use a initialize
> 'SharedPromoteIsTriggered' value first time I exec t
Hello,
When I test the patch, I find an issue: I start a stream with
'promote_trigger_file'
GUC valid, and exec pg_wal_replay_pause() during recovery and as below it
shows success to pause at the first time. I think it use a initialize
'SharedPromoteIsTriggered' value first time I exec the pg_wal
On 2020/03/10 2:27, Robert Haas wrote:
On Mon, Mar 9, 2020 at 12:03 PM Fujii Masao wrote:
I started the discussion about the topic very related to this.
I'm thinking to apply the change that Sergei proposes after applying
the patch I attached in this thread.
https://postgr.es/m/00c194b2-dbbb-
On Mon, Mar 9, 2020 at 12:03 PM Fujii Masao wrote:
> I started the discussion about the topic very related to this.
> I'm thinking to apply the change that Sergei proposes after applying
> the patch I attached in this thread.
> https://postgr.es/m/00c194b2-dbbb-2e8a-5b39-13f14048e...@oss.nttdata.c
On 2020/03/09 21:30, David Steele wrote:
Hi Sergei,
On 1/30/20 12:00 PM, Fujii Masao wrote:
- check for standby triggers only for recovery_target_action - I am not sure
this would be safe for pg_wal_replay_pause() call case
Agreed. Basically I think that recoveryPausesHere() should the
Hi Sergei,
On 1/30/20 12:00 PM, Fujii Masao wrote:
- check for standby triggers only for recovery_target_action - I am
not sure this would be safe for pg_wal_replay_pause() call case
Agreed. Basically I think that recoveryPausesHere() should the promotion
trigger whether recovery target is r
On 2020/01/30 20:00, Sergei Kornilov wrote:
Hello
Currently during point-in-time recovery with recovery_target_action = 'pause'
we print log lines:
LOG: recovery has paused
HINT: Execute pg_wal_replay_resume() to continue.
My colleague told me that this is a terrible moment: to continue
Hello
Currently during point-in-time recovery with recovery_target_action = 'pause'
we print log lines:
> LOG: recovery has paused
> HINT: Execute pg_wal_replay_resume() to continue.
My colleague told me that this is a terrible moment: to continue what exactly?
It sounds like "to continue repl
26 matches
Mail list logo
