Horton

Re: Sequence Access Methods, round two

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Michael Paquier <michael@paquier.xyz>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-08T15:06:36Z
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 19.01.24 00:27, Michael Paquier wrote:
> The reason why this stuff has bumped into my desk is that we have no
> good solution in-core for globally-distributed transactions for
> active-active deployments.  First, anything we have needs to be
> plugged into default expressions of attributes like with [1] or [2],
> or a tweak is to use sequence values that are computed with different
> increments to avoid value overlaps across nodes.  Both of these
> require application changes, which is meh for a bunch of users.

I don't follow how these require "application changes".  I guess it 
depends on where you define the boundary of the "application".  The 
cited solutions require that you specify a different default expression 
for "id" columns.  Is that part of the application side?  How would your 
solution work on that level?  AFAICT, you'd still need to specify the 
sequence AM when you create the sequence or identity column.  So you'd 
need to modify the DDL code in any case.