| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | Igor(dot)Lahnov(at)nexign(dot)com |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org, Alexey(dot)Timonin(at)nexign(dot)com, Andrey(dot)Dmitriyev(at)nexign(dot)com, Andrey(dot)Vassiliev(at)nexign(dot)com |
| Subject: | Re: Unable to start replica after failover |
| Date: | 2022-08-04 08:30:16 |
| Message-ID: | 20220804.173016.1842863543105077523.horikyota.ntt@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
At Fri, 29 Jul 2022 15:01:44 +0000, "Lahnov, Igor" <Igor(dot)Lahnov(at)nexign(dot)com> wrote in
> * "could not find previous WAL record at E6F/C2436F50: invalid resource manager ID 139 at E6F/C2436F50"; or
> * "could not find previous WAL record at 54E/FB348118: unexpected pageaddr 54E/7B34A000 in log segment 000000050000054E000000FB, offset 3448832".
..
> To avoid the problem, we decided to stop using restore_command. Could you please let us know if there is a better solution to the problem we've described?
Perhaps almost none of us don't see what is happning there, since you didn't give us sufficient information on the configuration and exact steps.
But roughly it looks like shuffling/mixing of WAL files among several
systems (or WAL archives) with different histories.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mateusz Henicz | 2022-08-04 08:32:42 | Re: BUG #17567: Unable to Set Max_Connection in Postgresql which has replicas |
| Previous Message | Francisco Olarte | 2022-08-04 07:51:01 | Re: Purpose of DEFERRABLE _and_ INITIALLY DEFERRED foreign key constraint checking? |