回复: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
От | Thomas wen |
---|---|
Тема | 回复: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Дата | |
Msg-id | SEZPR01MB4575D54AE9DBF13FB71C49AB86CBA@SEZPR01MB4575.apcprd01.prod.exchangelabs.com обсуждение исходный текст |
Ответ на | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) (Aleksander Alekseev <aleksander@timescale.com>) |
Список | pgsql-hackers |
> > This patch makes the filenames always 12 characters wide (for SLRUs that
> > opt-in to the new naming). That's actually not enough for the full range
> > that a 64 bit page number can represent. Should we make it 16 characters
> > now, to avoid repeating the same mistake we made earlier? Or make it
> > more configurable, on a per-SLRU basis. One reason I don't want to just
> > make it 16 characters is that WAL segment filenames are also 16 hex
> > characters, which could cause confusion.
>
> Good catch. I propose the following solution:
>
> ```
> SlruFileName(SlruCtl ctl, char *path, int64 segno)
> {
> if (ctl->long_segment_names)
> - return snprintf(path, MAXPGPATH, "%s/%012llX", ctl->Dir,
> + /*
> + * We could use 16 characters here but the disadvantage would be that
> + * the SLRU segments will be hard to distinguish from WAL segments.
> + *
> + * For this reason we use 15 characters. It is enough but also means
> + * that in the future we can't decrease SLRU_PAGES_PER_SEGMENT easily.
> + */
> + return snprintf(path, MAXPGPATH, "%s/%015llX", ctl->Dir,
> (long long) segno);
> else
> return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
> ```
>
> PFE the corrected patchset v58.
Good idea
> > opt-in to the new naming). That's actually not enough for the full range
> > that a 64 bit page number can represent. Should we make it 16 characters
> > now, to avoid repeating the same mistake we made earlier? Or make it
> > more configurable, on a per-SLRU basis. One reason I don't want to just
> > make it 16 characters is that WAL segment filenames are also 16 hex
> > characters, which could cause confusion.
>
> Good catch. I propose the following solution:
>
> ```
> SlruFileName(SlruCtl ctl, char *path, int64 segno)
> {
> if (ctl->long_segment_names)
> - return snprintf(path, MAXPGPATH, "%s/%012llX", ctl->Dir,
> + /*
> + * We could use 16 characters here but the disadvantage would be that
> + * the SLRU segments will be hard to distinguish from WAL segments.
> + *
> + * For this reason we use 15 characters. It is enough but also means
> + * that in the future we can't decrease SLRU_PAGES_PER_SEGMENT easily.
> + */
> + return snprintf(path, MAXPGPATH, "%s/%015llX", ctl->Dir,
> (long long) segno);
> else
> return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
> ```
>
> PFE the corrected patchset v58.
Good idea
发件人: Aleksander Alekseev <aleksander@timescale.com>
发送时间: 2023年9月4日 22:41
收件人: Postgres hackers <pgsql-hackers@lists.postgresql.org>
抄送: Heikki Linnakangas <hlinnaka@iki.fi>; Maxim Orlov <orlovmg@gmail.com>; Jacob Champion <jchampion@timescale.com>; Japin Li <japinli@hotmail.com>; Andres Freund <andres@anarazel.de>; Michael Paquier <michael@paquier.xyz>; Pavel Borisov <pashkin.elfe@gmail.com>; Peter Eisentraut <peter.eisentraut@enterprisedb.com>; Alexander Korotkov <aekorotkov@gmail.com>
主题: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
发送时间: 2023年9月4日 22:41
收件人: Postgres hackers <pgsql-hackers@lists.postgresql.org>
抄送: Heikki Linnakangas <hlinnaka@iki.fi>; Maxim Orlov <orlovmg@gmail.com>; Jacob Champion <jchampion@timescale.com>; Japin Li <japinli@hotmail.com>; Andres Freund <andres@anarazel.de>; Michael Paquier <michael@paquier.xyz>; Pavel Borisov <pashkin.elfe@gmail.com>; Peter Eisentraut <peter.eisentraut@enterprisedb.com>; Alexander Korotkov <aekorotkov@gmail.com>
主题: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Hi,
> > Reviewing this now. I think it's almost ready to be committed.
> >
> > There's another big effort going on to move SLRUs to the regular buffer
> > cache (https://commitfest.postgresql.org/43/3514/). I wonder how moving
> > to 64 bit page numbers will affect that. BlockNumber is still 32 bits,
> > after all.
>
> Somehow I didn't pay too much attention to this effort, thanks. I will
> familiarize myself with the patch. Intuitively I don't think that the
> patchse should block each other.
>
> > This patch makes the filenames always 12 characters wide (for SLRUs that
> > opt-in to the new naming). That's actually not enough for the full range
> > that a 64 bit page number can represent. Should we make it 16 characters
> > now, to avoid repeating the same mistake we made earlier? Or make it
> > more configurable, on a per-SLRU basis. One reason I don't want to just
> > make it 16 characters is that WAL segment filenames are also 16 hex
> > characters, which could cause confusion.
>
> Good catch. I propose the following solution:
>
> ```
> SlruFileName(SlruCtl ctl, char *path, int64 segno)
> {
> if (ctl->long_segment_names)
> - return snprintf(path, MAXPGPATH, "%s/%012llX", ctl->Dir,
> + /*
> + * We could use 16 characters here but the disadvantage would be that
> + * the SLRU segments will be hard to distinguish from WAL segments.
> + *
> + * For this reason we use 15 characters. It is enough but also means
> + * that in the future we can't decrease SLRU_PAGES_PER_SEGMENT easily.
> + */
> + return snprintf(path, MAXPGPATH, "%s/%015llX", ctl->Dir,
> (long long) segno);
> else
> return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
> ```
>
> PFE the corrected patchset v58.
While triaging the patches for the September CF [1] a consensus was
reached that the patchset needs another round of review. Also I
removed myself from the list of reviewers in order to make it clear
that a review from somebody else would be appreciated.
[1]: https://postgr.es/m/0737f444-59bb-ac1d-2753-873c40da0840%40eisentraut.org
--
Best regards,
Aleksander Alekseev
> > Reviewing this now. I think it's almost ready to be committed.
> >
> > There's another big effort going on to move SLRUs to the regular buffer
> > cache (https://commitfest.postgresql.org/43/3514/). I wonder how moving
> > to 64 bit page numbers will affect that. BlockNumber is still 32 bits,
> > after all.
>
> Somehow I didn't pay too much attention to this effort, thanks. I will
> familiarize myself with the patch. Intuitively I don't think that the
> patchse should block each other.
>
> > This patch makes the filenames always 12 characters wide (for SLRUs that
> > opt-in to the new naming). That's actually not enough for the full range
> > that a 64 bit page number can represent. Should we make it 16 characters
> > now, to avoid repeating the same mistake we made earlier? Or make it
> > more configurable, on a per-SLRU basis. One reason I don't want to just
> > make it 16 characters is that WAL segment filenames are also 16 hex
> > characters, which could cause confusion.
>
> Good catch. I propose the following solution:
>
> ```
> SlruFileName(SlruCtl ctl, char *path, int64 segno)
> {
> if (ctl->long_segment_names)
> - return snprintf(path, MAXPGPATH, "%s/%012llX", ctl->Dir,
> + /*
> + * We could use 16 characters here but the disadvantage would be that
> + * the SLRU segments will be hard to distinguish from WAL segments.
> + *
> + * For this reason we use 15 characters. It is enough but also means
> + * that in the future we can't decrease SLRU_PAGES_PER_SEGMENT easily.
> + */
> + return snprintf(path, MAXPGPATH, "%s/%015llX", ctl->Dir,
> (long long) segno);
> else
> return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
> ```
>
> PFE the corrected patchset v58.
While triaging the patches for the September CF [1] a consensus was
reached that the patchset needs another round of review. Also I
removed myself from the list of reviewers in order to make it clear
that a review from somebody else would be appreciated.
[1]: https://postgr.es/m/0737f444-59bb-ac1d-2753-873c40da0840%40eisentraut.org
--
Best regards,
Aleksander Alekseev
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "David G. Johnston"Дата:
Сообщение: Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector