Horton

Re: Sequence Access Methods, round two

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Kirill Reshke <reshkekirill@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-18T04:52:45Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Refactor init_params() in sequence.c to not use FormData_pg_sequence_data

  2. Fix comment thinko in sequence.c

  3. Group more closely cache updates for backends in sequence.c

  4. Introduce sequence_*() access functions

Attachments

On Thu, Nov 13, 2025 at 08:51:32AM +0900, Michael Paquier wrote:
> Err, no.  It's the opposite here: code cleanups and file splits are
> cleaner if they happen first, not after the implementations as these
> lead to less code churn overall.  Splitting the sequence "core" logic
> and WAL logic make sense in the long-term to me anyway, as a separate
> refactoring piece.  It's true that 0002 could be slightly different,
> though, we could for example keep sequence.c where it is now in
> src/backend/commands/ without forcing the use of the term "AM" in the
> file names, and extract the WAL pieces of it into a new file (aka the
> redo and marking routines).  Then it's only a game of moving the files
> around depending on the follow-up pieces.  I should probably post a
> patch for that separately, this has been bugging me a bit in terms of
> code separation clarity for the sequence RMGR.

Since this update, the code related to the sequence RMGR has been
moved around with a87987cafca6.  This makes the rebased version of the
patch leaner, with a cleaner split between the WAL and "core"
computation logic, as v24 and older patch sets submitted on this
thread were splitting this code already.

Anyway.  Rebased.  v25.  Attached.
--
Michael