Horton

Re: Sequence Access Methods, round two

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Peter Smith <smithpb2250@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-26T08:10: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

On Thu, Feb 22, 2024 at 05:36:00PM +0100, Tomas Vondra wrote:
> 0002, 0003
> ------------
> seems fine, cosmetic changes

Thanks, I've applied these two for now.  I'll reply to the rest
tomorrow or so.

By the way, I am really wondering if the update of elm->increment in
nextval_internal() should be treated as a bug?  In the "fetch" cache
if a sequence does not use cycle, we may fail when reaching the upper
or lower bound for respectively an ascending or descending sequence,
while still keeping what could be an incorrect value if values are
cached on a follow-up nextval_internal call?
--
Michael