Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: jeff.janes@gmail.com, mk@071.ovh, pgsql-bugs@lists.postgresql.org
Date: 2021-07-19T21:24:48Z
Lists: pgsql-bugs
On 2021-Jul-19, Kyotaro Horiguchi wrote: > Sorry for the mistake. It seems to me the cause the above is that > segment removal happens *after* invalidation. Since (at least > currently) the "slot is invalidated" warning issued only at the time > just before WAL-removal, we should expect that old segments are gone > after the checkpoint-ending log, which should be seen after > WAL-removal. If not, that shows that there's a bug. > > What do you think about the attached? Sounds sensible -- I verified the logs for one of the cases that failed in the buildfarm, and indeed the "checkpoint ended" message appears after the s2 slot is created, so it should fix the problem. (I didn't actually try to reproduce the problem locally, so I didn't verify the fix any further than ensuring the test still passes.) Pushed, thanks! -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Commits
-
Close yet another race condition in replication slot test code
- 41d27ee7b870 13.4 landed
- f951f6f69c7e 14.0 landed
- ce197e91d02c 15.0 landed
-
Make new replication slot test code even less racy
- ce413eba4116 13.4 landed
- 1e8751380836 14.0 landed
- 0d2cb6b2bbc3 15.0 landed
-
Make new replication slot test code less racy
- d8f3b021c618 14.0 landed
- 8589299e03ff 15.0 landed
- 7099ba058035 13.4 landed
-
Advance old-segment horizon properly after slot invalidation
- ead9e51e8236 15.0 landed
- e5bcbb10707b 14.0 landed
- 866237a6fa01 13.4 landed