Re: [PATCH] Refactor SLRU to always use long file names

On Thu, Sep 12, 2024 at 12:33:14PM +0300, Aleksander Alekseev wrote:
> It wouldn't hurt re-checking the segment file names in the TAP test
> but this would mean hardcoding catalog names which as I understand you
> want to avoid. With high probability PG wouldn't start if the
> corresponding piece of pg_upgrade is wrong (I checked more than once
> :). So I'm not entirely sure if it's worth the effort, but let's see
> what others think.

+ segno = strtoi64(de->d_name, NULL, 16);
+ snprintf(new_path, MAXPGPATH, "%s/%015llX", dir_path,
+ (long long) segno);
+ snprintf(old_path, MAXPGPATH, "%s/%s", dir_path, de->d_name);
+
+ if (pg_mv_file(old_path, new_path) != 0)
+ pg_fatal("could not rename file \"%s\" to \"%s\": %m",
+ old_path, new_path);

Your patch is just doing a rename() of the files from short to long
names. How about adding a new TAP script in pg_upgrade that creates a
couple of empty files with short files names in each path that needs
to do the transfer? Then the test could run one pg_upgrade command
and check that the new names are in place. You could use a array of
objects, with the base path, the old name and the new name, then loop
over it. With the check in check_slru_segment_filenames() based on
SLRU_SEG_FILENAMES_CHANGE_CAT_VER, that should work.

+ static const char* dirs[] = {
+ "pg_xact",
+ "pg_commit_ts",
+ "pg_multixact/offsets",
+ "pg_multixact/members",
+ "pg_subtrans",
+ "pg_serial",
+ };

Hardcoding that is always annoying, but well, that's not going to
change. So living with this is not going to be a maintenance burden.
--
Michael