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.
--
Best regards,
Aleksander Alekseev
v58-0003-Make-use-FullTransactionId-in-2PC-filenames.patch
Description: Binary data
v58-0001-Index-SLRUs-by-64-bit-integers-rather-than-by-32.patch
Description: Binary data
v58-0002-Use-larger-segment-file-names-for-pg_notify.patch
Description: Binary data
