Re: Sequence Access Methods, round two

> On Dec 26, 2025, at 13:45, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Dec 24, 2025 at 04:14:06PM +0800, Chao Li wrote:
>> Okay, a clean build has made the patch working for me. I did some
>> basic tests and went through all commits. After 26 rounds of
>> revision, this patch now looks solid already. Here comes my
>> comments:
>
> Thanks for the review.
>
>> 3 - 0002 - seqlocalam.c
>> +static void
>> +fill_seq_with_data(Relation rel, HeapTuple tuple)
>> +{
>> ```
>>
>> This function handles unlogged logic, but should UNLOGGED be handled
>> by the core?
>
> That is something I have considered while splitting the code, but this
> makes the init() and reset() callbacks weirder in shape as, so the
> separation felt more natural to me, leaving up to the AM layer what
> should be done.  So the answer from me is nope on this one.

Then that has to be documented clearly. Meaning that, if a user chooses to use a non-default sequence AM, then UNLOGGED
mightnot work, I don’t see a mechanism to enforce a custom AM to honor UNLOGGED. 

>
>> I am thinking if we should use the constant
>> DEFAULT_TABLE_ACCESS_METHOD that is also “heap” today. My theory is
>> that, in future, PG introduces a new table access method, say
>> “heap_ex” (enhanced heap”), and switch to use it,
>> DEFAULT_TABLE_ACCESS_METHOD will be updated to “heap_ex”, then I
>> guess local sequence am should switch to use “heap_ex” for table am
>> as well.
>
> Using DEFAULT_TABLE_ACCESS_METHOD makes sense I guess.  I doubt that
> we'll ever rename that, though.

I didn’t mean to suggest that we would ever rename “heap” to “heap_ex”. That was just an example to illustrate that, at
somepoint in the future, a new default table AM might be introduced. If we use the constant today, it reduces the risk
offorgetting to update this code when such a change happens. 

>> 12 - 0006
>> This macro assumes the caller has buf, page, sm, tuple, rel and
>> forkNum, which makes the macro fragile. Actually, buf, page and sm
>> are purely local and temp, they can be defined within the do{}while
>> block, and tuple, rel and forkNum can be passed in as
>> arguments. Also, given this macro is relatively long, maybe consider
>> an inline static function.
>>
>> 13 - 0006
>> This macro not only assumes the caller has buf, also update
>> buf. Maybe a static inline function is better here.
>
> These two are intentional for one reason: it makes people aware that
> pages should have a special area enforced with a specific type and
> that the special area should be cross-checked on read.  It is true
> that in the init() case we could return a Buffer and pass the size of
> the special area, setting the contents of the special area outside,
> but the second case brings trouble as the special area should be
> checked before reading any fields from the page.  Perhaps the case for
> this layer is not that much justified, this only mimics the core
> sequence method that relies on a single page per sequence with a
> buffer lock when getting a value.

Should the macro comment documents something like: “to use this macro, the caller must define the following variables
1)Buffer buf;, 2) Page page;, 3) seam_speical *sm;” If we use a function, the interface is clear; to use a macro, the
interfaceand dependencies are not that clear, so more documentation is needed. 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/