Re: pg_rewind WAL segments deletion pitfall
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: cyberdemn@gmail.com
Cc: michael@paquier.xyz, torikoshia@oss.nttdata.com,
pgsql-hackers@postgresql.org, bungina@gmail.com,
pgsql-hackers@lists.postgresql.org
Date: 2023-08-24T00:45:38Z
Lists: pgsql-bugs, pgsql-hackers
At Wed, 23 Aug 2023 13:44:52 +0200, Alexander Kukushkin <cyberdemn@gmail.com> wrote in > On Tue, 22 Aug 2023 at 07:32, Michael Paquier <michael@paquier.xyz> wrote: > > I don't like much this patch. While it takes correctly advantage of > > the backward record read logic from SimpleXLogPageRead() able to > > handle correctly timeline jumps, it creates a hidden dependency in the > > code between the hash table from filemap.c and the page callback. > > Wouldn't it be simpler to build a list of the segment names using the > > information from WALOpenSegment and build this list in > > findLastCheckpoint()? > > I think the first version of the patch more or less did that. Not > necessarily a list, but a hash table of WAL file names that we want to > keep. But Kyotaro Horiguchi didn't like it and suggested creating entries > in the filemap.c hash table instead. > But, I agree, doing it directly from the findLastCheckpoint() makes the > code easier to understand. ... > > + /* > > + * Some entries (WAL segments) already have an action assigned > > + * (see SimpleXLogPageRead()). > > + */ > > + if (entry->action == FILE_ACTION_UNDECIDED) > > + entry->action = decide_file_action(entry); > > > > This change makes me a bit uneasy, per se my previous comment with the > > additional code dependencies. > > > > We can revert to the original approach (see > v1-0001-pg_rewind-wal-deletion.patch from the very first email) if you like. On the other hand, that approach brings in another source that suggests the way that file should be handled. I still think that entry->action should be the only source. However, it seems I'm in the minority here. So I'm not tied to that approach. > > I think that this scenario deserves a test case. If one wants to > > emulate a delay in WAL archiving, it is possible to set > > archive_command to a command that we know will fail, for instance. > > > > Yes, I totally agree, it is on our radar, but meanwhile please see the new > version, just to check if I correctly understood your idea. Agreed. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Fix newly introduced 010_keep_recycled_wals.pl
- 2fb3919356fb 17.3 landed
- 50010c6f6c4d 16.7 landed
- 93d8d4fe1255 15.11 landed
- 1c5fe56bc259 14.16 landed
- b5be29ecafe1 18.0 landed
-
Avoid deleting critical WAL segments during pg_rewind
- ea1649c352f6 16.6 landed
- e28cf2fbc222 15.10 landed
- cb844d66b587 17.2 landed
- ba25358413e4 14.15 landed
- 90bcc7c2db1d 18.0 landed