From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Polina Bungina <bungina(at)gmail(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, cyberdemn(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_rewind WAL segments deletion pitfall |
Date: | 2023-06-28 13:28:13 |
Message-ID: | 2e75ae22dce9a227c3d47fa6d0ed094a@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2022-09-29 17:18, Polina Bungina wrote:
> I agree with your suggestions, so here is the updated version of
> patch. Hope I haven't missed anything.
>
> Regards,
> Polina Bungina
Thanks for working on this!
It seems like we are also facing the same issue.
I tested the v3 patch under our condition, old primary has succeeded to
become new standby.
BTW when I used pg_rewind-removes-wal-segments-reproduce.sh attached in
[1], old primary also failed to become standby:
FATAL: could not receive data from WAL stream: ERROR: requested WAL
segment 000000020000000000000007 has already been removed
However, I think this is not a problem: just adding restore_command
like below fixed the situation.
echo "restore_command = '/bin/cp `pwd`/newarch/%f %p'" >>
oldprim/postgresql.conf
Attached modified reproduction script for reference.
[1]/message-id/CAFh8B%3DnNiFZOAPsv49gffxHBPzwmZ%3D6Msd4miMis87K%3Dd9rcRA%40mail.gmail.com
--
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
pg_rewind-removes-wal-segments-reproduce2.sh | text/plain | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-06-28 18:49:34 | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Previous Message | David Rowley | 2023-06-28 10:28:32 | Re: BUG #18002: Duplicate entries of row possible even after having primary key |
From | Date | Subject | |
---|---|---|---|
Next Message | Alena Rybakina | 2023-06-28 13:53:06 | Re: MergeJoin beats HashJoin in the case of multiple hash clauses |
Previous Message | Japin Li | 2023-06-28 13:26:02 | Re: Another incorrect comment for pg_stat_statements |