Hello
> If we don't ignore walreceiver and does try to connect to the master,
> a promotion and recovery cannot end forever since new WAL data can
> be streamed. You think this behavior is more consistent?
We have no simple point to stop replay.
Well, except for "immediately" - just one easy stop
On 2020/03/25 19:42, Sergei Kornilov wrote:
Hi
Could we add a few words in func.sgml to clarify the behavior? Especially for
users from my example above. Something like:
If a promotion is triggered while recovery is paused, the paused state ends,
replay of any WAL immediately availab
Hi
>> Could we add a few words in func.sgml to clarify the behavior? Especially
>> for users from my example above. Something like:
>>
>>> If a promotion is triggered while recovery is paused, the paused state
>>> ends, replay of any WAL immediately available in the archive or in pg_wal
>>> w
On 2020/03/25 0:17, Sergei Kornilov wrote:
Hello
I pushed the latest version of the patch. If you have further opinion
about immediate promotion, let's keep discussing that!
Thank you!
Honestly, I forgot that the promotion is documented in high-availability.sgml
as:
Before failover, an
Hello
> I pushed the latest version of the patch. If you have further opinion
> about immediate promotion, let's keep discussing that!
Thank you!
Honestly, I forgot that the promotion is documented in high-availability.sgml
as:
> Before failover, any WAL immediately available in the archive or
On 2020/03/24 0:57, Fujii Masao wrote:
On 2020/03/24 0:17, Sergei Kornilov wrote:
Hello
You meant that the promotion request should cause the recovery
to finish immediately even if there are still outstanding WAL records,
and cause the standby to become the master?
Oh, I get your point.
On 2020/03/24 0:17, Sergei Kornilov wrote:
Hello
You meant that the promotion request should cause the recovery
to finish immediately even if there are still outstanding WAL records,
and cause the standby to become the master?
Oh, I get your point. But yes, I expect that in case of promoti
On 2020/03/23 23:55, Robert Haas wrote:
On Mon, Mar 23, 2020 at 10:36 AM Fujii Masao
wrote:
If we would like to have the promotion method to finish recovery
immediately, IMO we should implement something like
"pg_ctl promote -m fast". That is, we need to add new method into
the promotion.
Hello
> You meant that the promotion request should cause the recovery
> to finish immediately even if there are still outstanding WAL records,
> and cause the standby to become the master?
Oh, I get your point. But yes, I expect that in case of promotion request
during a pause, the user (me too
On Mon, Mar 23, 2020 at 10:36 AM Fujii Masao
wrote:
> If we would like to have the promotion method to finish recovery
> immediately, IMO we should implement something like
> "pg_ctl promote -m fast". That is, we need to add new method into
> the promotion.
I think 'immediate' would be a better c
On 2020/03/23 22:46, Sergei Kornilov wrote:
Hello
(I am trying to find an opportunity to review this patch...)
Thanks for the review! It's really helpful!
Consider test case with streaming replication:
on primary: create table foo (i int);
on standby:
postgres=# select pg_wal_replay_pa
Hello
(I am trying to find an opportunity to review this patch...)
Consider test case with streaming replication:
on primary: create table foo (i int);
on standby:
postgres=# select pg_wal_replay_pause();
pg_wal_replay_pause
-
(1 row)
postgres=# select pg_is_wal_replay_
On 2020/03/20 15:22, Atsushi Torikoshi wrote:
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
OK, so patch attached.
This patch causes, if a promotion is triggered while recovery is paused,
the paused state to end and a promotion to conti
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao
wrote:
>
> OK, so patch attached.
>
> This patch causes, if a promotion is triggered while recovery is paused,
> the paused state to end and a promotion to continue. OTOH, this patch
> makes pg_wal_replay_pause() and _resume() throw an error if it's exe
On 2020/03/04 23:40, Jehan-Guillaume de Rorthais wrote:
On Wed, 04 Mar 2020 15:00:54 +0300
Sergei Kornilov wrote:
Hello
I want to start this discussion because this is related to the patch
(propoesd at the thread [1]) that I'm reviewing. It does that partially,
i.e., prefers the promotion
On Wed, 04 Mar 2020 15:00:54 +0300
Sergei Kornilov wrote:
> Hello
>
> > I want to start this discussion because this is related to the patch
> > (propoesd at the thread [1]) that I'm reviewing. It does that partially,
> > i.e., prefers the promotion only when the pause is requested by
> > recove
Hello
> I want to start this discussion because this is related to the patch
> (propoesd at the thread [1]) that I'm reviewing. It does that partially,
> i.e., prefers the promotion only when the pause is requested by
> recovery_target_action=pause. But I think that it's reasonable and
> more cons
Hi,
Currently if pg_wal_replay_pause() is called after the standby
promotion is triggerred before the promotion has successfully
finished, WAL replay is paused. That is, the replay pause is
preferred than the promotion. Is this desiderable behavior?
ISTM that most users including me want the rec
18 matches
Mail list logo
