Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Date
Msg-id CAJ7c6TN1hKqNPGrNcq96SUyD=Z61raKGXF8iqq36qr90oudxRg@mail.gmail.com
Whole thread Raw
In response to Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi Alexander,

> -#define TransactionIdToCTsPage(xid) \
> -   ((xid) / (TransactionId) COMMIT_TS_XACTS_PER_PAGE)
> +
> +/*
> + * Although we return an int64 the actual value can't currently exceeed 2**32.
> + */
> +static inline int64
> +TransactionIdToCTsPage(TransactionId xid)
> +{
> +   return xid / (int64) COMMIT_TS_XACTS_PER_PAGE;
> +}
>
> Is there any reason we transform macro into a function?  If not, I propose to leave this as a macro.  BTW, there is a
typoin a word "exceeed". 

I kept the inline function, as we agreed above.

Typo fixed.

> +static int inline
> +SlruFileName(SlruCtl ctl, char *path, int64 segno)
> +{
> +   if (ctl->long_segment_names)
> +       /*
> +        * 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,
> +                       (unsigned int) segno);
> +}
>
> I think it worth adding asserts here to verify there is no overflow making us mapping different segments into the
samefiles. 

Added. I noticed a off-by-one error in the code snippet proposed
above, so my code differs a bit.

> +   return occupied == max_notify_queue_pages;
>
> I'm not sure if the current code could actually allow to occupy more than max_notify_queue_pages.  Probably not even
inextreme cases.  But I still think it will more safe and easier to read to write "occupied >= max_notify_queue"_pages
here.

Fixed.

> diff --git a/src/test/modules/test_slru/test_slru.c b/src/test/modules/test_slru/test_slru.c
>
> The actual 64-bitness of SLRU pages isn't much exercised in our automated tests.  It would be too exhausting to make
pg_notifyactually use higher than 2**32 page numbers.  Thus, I think test/modules/test_slru is a good place to give
highpage numbers a good test. 

Fixed. I choose not to change any numbers in the test in order to
check any corner cases, etc. The code patches for long_segment_names =
true and long_segment_names = false are almost the same thus it will
not improve code coverage. Using the current numbers will allow to
easily switch back to long_segment_names = false in the test if
necessary.

PFA the corrected patchset v59.

--
Best regards,
Aleksander Alekseev

Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: RFC: Pluggable TOAST
Next
From: Aleksander Alekseev
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)