From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com> |
Cc: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: replay pause vs. standby promotion |
Date: | 2020-03-23 13:46:52 |
Message-ID: | 9842121584969106@myt5-b646bde4b8f3.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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_paused();
pg_is_wal_replay_paused
-------------------------
t
(1 row)
postgres=# table foo;
i
---
(0 rows)
Execute "insert into foo values (1);" on primary
postgres=# select pg_promote ();
pg_promote
------------
t
(1 row)
postgres=# table foo;
i
---
1
And we did replay one additional change during promote. I think this is wrong behavior. Possible can be fixed by
+ if (PromoteIsTriggered()) break;
/* Setup error traceback support for ereport() */
errcallback.callback = rm_redo_error_callback;
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-03-23 14:24:50 | Re: WAL usage calculation patch |
Previous Message | Ashutosh Bapat | 2020-03-23 13:41:54 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |