| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, hubert depesz lubaczewski <depesz(at)depesz(dot)com>, pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Loss of replication after simple misconfiguration |
| Date: | 2020-04-10 05:43:15 |
| Message-ID: | 20200410054315.GV1606@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Apr 10, 2020 at 01:14:34PM +0900, Michael Paquier wrote:
> I have been able to write a TAP test to reproduce this exact scenario,
> though it succeeds for me (it could be a good idea to add some
> coverage for that actually..). Perhaps I am missing a step though?
> For example, perhaps the original setting was track_commit_timestamp =
> on, then it got disabled once?
I have been looking at more scenarios involving switching back and
forth track_commit_timestamps on/off during a switchover with a
standby failing to replay a XLOG_CHANGE_PARAMETER record during
recovery, still I cannot see a failure in scenarios close to what is
discussed here (the test includes transactions replayed with and
without the switch). Attached is a more advanced test. Any thoughts?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| committs-switchover-test-v2.patch | text/x-diff | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2020-04-10 07:26:51 | Re: Loss of replication after simple misconfiguration |
| Previous Message | Michael Paquier | 2020-04-10 04:14:34 | Re: Loss of replication after simple misconfiguration |