On Fri, Feb 4, 2022 at 5:33 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > > Thanks. I get it. For syncing map files, we don't want to tolerate any > > errors, whereas removal of the old map files (lesser than cutoff LSN) > > can be tolerated in CheckPointLogicalRewriteHeap. > > LGTM. Andres noted upthread [0] that the comment above sscanf() about > skipping editors' lock files might not be accurate. I don't think it's a > huge problem if sscanf() matches those files, but perhaps we can improve > the comment. > > [0] https://postgr.es/m/20220120194618.hmfd4kxkng2cgryh%40alap3.anarazel.de
Andres comment from [0]: > An editor's lock file that starts with map- would presumably be the whole > filename plus an additional file-ending. But this check won't catch those. Agreed. sscanf checks can't detect the files named "whole filename plus an additional file-ending". I just checked with vi editor lock state file .0-14ED3B8.snap.swp [1], the log generated is [2]. I'm not sure exactly which editor would create a lockfile like "whole filename plus an additional file-ending". In any case, let's remove the editor's lock/state file from those comments and have just only "We just log a message if a file doesn't fit the pattern". Attached v8 patch with that change. [1] -rw------- 1 bharath bharath 12288 Feb 10 15:48 .0-14ED3B8.snap.swp -rw------- 1 bharath bharath 128 Feb 10 15:48 0-14ED518.snap -rw------- 1 bharath bharath 128 Feb 10 15:49 0-14ED518.snap.lockfile -rw------- 1 bharath bharath 128 Feb 10 15:49 0-14ED550.snap -rw------- 1 bharath bharath 128 Feb 10 15:49 0-14ED600.snap [2] 2022-02-10 15:48:47.938 UTC [1121678] LOG: could not parse file name "pg_logical/snapshots/.0-14ED3B8.snap.swp" Regards, Bharath Rupireddy.
v8-0001-Replace-ReadDir-with-ReadDirExtended.patch
Description: Binary data
