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
