Re: WAL segments removed from primary despite the fact that logical replication slot needs it.
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: depesz@depesz.com
Cc: pgsql-bugs mailing list <pgsql-bugs@postgresql.org>
Date: 2022-11-14T16:22:05Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix a possibility of logical replication slot's restart_lsn going backwards.
- e5ed873b1b4a 18.0 landed
- 568e78a653ee 17.2 landed
- f353911337cf 16.6 landed
- 91771b3fbbc3 15.10 landed
- 26c4e8968690 14.15 landed
- 15dc1abb17dd 13.18 landed
On Mon, Nov 14, 2022 at 7:03 PM hubert depesz lubaczewski <depesz@depesz.com> wrote: > > On Mon, Nov 14, 2022 at 06:30:57PM +0530, Amit Kapila wrote: > > > There is something weird happening: > > What exactly weird you are seeing in this? To me, it appears as if the > > system due to some reason ignores an existing slot that has > > restart_lsn as 1039D/83825958. > > The weird part for me is that it is trying to remove wal files older > than the same "x" many times. > I think that is okay because as per checkpointer's computation it decides not to remove/replace any new WAL files. At this stage, I am not getting any idea except for getting the value of XLogGetReplicationSlotMinimumLSN() in one of the LOG prints. If you can't add all the LOGs, I shared in the last patch, can you try to get the value of XLogGetReplicationSlotMinimumLSN() by appending to the existing LOG "attempting to remove WAL segments older than log file .."? -- With Regards, Amit Kapila.