| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly |
| Date: | 2016-08-26 02:43:26 |
| Message-ID: | CAB7nPqSJ429SiWc83s0YJYM-yqLotQ5=g_fF=6--WHwPQA6MmA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 26, 2016 at 11:33 AM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> Our customer hit a problem of cascading replication, and we found the cause. They are using the latest PostgreSQL 9.2.18. The bug seems to have been fixed in 9.4 and higher during the big modification of xlog.c, but it's not reflected in older releases.
>
> The attached patch is for 9.2.18. This just borrows the idea from 9.4 and higher.
>
> But we haven't been able to reproduce the problem. Could you review the patch and help to test it? I would very much appreciate it if you could figure out how to reproduce the problem easily.
> [...]
> LOG: out-of-sequence timeline ID 140 (after 141) in log file 652, segment 117, offset 0
9.3 has addressed that by allowing streaming standbys to perform
timeline jumps via the replication protocol. Doesn't this problem
enter in this area?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2016-08-26 02:55:39 | Re: Renaming of pg_xlog and pg_clog |
| Previous Message | Michael Paquier | 2016-08-26 02:39:29 | Renaming of pg_xlog and pg_clog |