Re: [PATCH] Refactor SLRU to always use long file names
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: [PATCH] Refactor SLRU to always use long file names |
| Дата | |
| Msg-id | 8da558b6-14fe-4f04-a6bd-98e9961c9ff5@iki.fi обсуждение исходный текст |
| Ответ на | Re: [PATCH] Refactor SLRU to always use long file names (Aleksander Alekseev <aleksander@tigerdata.com>) |
| Ответы |
Re: [PATCH] Refactor SLRU to always use long file names
|
| Список | pgsql-hackers |
On 06/01/2026 17:18, Aleksander Alekseev wrote:
> +static void
> +check_slru_segment_filenames(void)
> +{
> + int i;
> + static const char* dirs[] = {
> + "pg_xact",
> + "pg_commit_ts",
> + "pg_multixact/offsets",
> + "pg_multixact/members",
> + "pg_subtrans",
> + "pg_serial",
> + };
> +
> + if(old_cluster.controldata.cat_ver >= SLRU_SEG_FILENAMES_CHANGE_CAT_VER)
> + return;
> +
> + for (i = 0; i < sizeof(dirs)/sizeof(dirs[0]); i++)
> + rename_slru_segments(dirs[i]);
> +}
Since commit bd8d9c9bdf "Widen MultiXactOffset to 64 bits",
"pg_multixact/members" should not be in that list anymore.
Also, it seems misleading that a function called "check_*" doesn't
merely check for things, but renames files. Also, it seems silly to
first copy/link the files with the old short names, and rename them
later. Could we copy/link them with the new long names to begin with?
(No comment on whether this is a good idea in general or the rest of the
patch)
- Heikki
В списке pgsql-hackers по дате отправления: