Re: Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-24T03:51:44Z
Lists: pgsql-hackers
Attachments
- postgresql_Thu_Patch.log (application/octet-stream)
- postgresql_Thu_Head.log (application/octet-stream)
- cascading_standby_stuck_v3.patch (application/octet-stream) patch v3
On Tue, Nov 22, 2016 at 8:48 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > From: pgsql-hackers-owner@postgresql.org > > If the problem occurs, the following pair of lines appear in the server log of the cascading standby. Could you check it? > > LOG: restored log file "000000020000000000000003" from archive > LOG: out-of-sequence timeline ID 1 (after 2) in log file 0, segment 3, offset 0 > Thanks for the clarification, I could reproduce the issue and confirms that patch has fixed it. Find logs of cascading standby at PG9.2 Head and Patch attached (I have truncated few lines at end of server log generated in Head as those were repetitive). I think the way you have directly explained the bug steps in code comments is not right (think if we start writing bug steps for each bug fix, how the code will look like). So I have modified the comment to explain the situation and reason of check, see if you find that as okay? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Fix bug in verifying TLI (timeline ID) in WAL page header during recovery..
- 38bec18056b8 9.2.20 landed
-
Split out XLog reading as an independent facility
- 7fcbf6a405ff 9.3.0 cited