Re: Logical Replication of sequences

vignesh C <vignesh21@gmail.com>

From: vignesh C <vignesh21@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: Nisha Moond <nisha.moond412@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2025-07-11T09:26:39Z
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. Doc: Add documentation for sequence synchronization.

  2. Remove unused assignment in CREATE PUBLICATION grammar.

  3. Add seq_sync_error_count to subscription statistics.

  4. Fix few issues in commit 5509055d69.

  5. Add sequence synchronization for logical replication.

  6. Add worker type argument to logical replication worker functions.

  7. Introduce "REFRESH SEQUENCES" for subscriptions.

  8. Refactor logical worker synchronization code into a separate file.

  9. Standardize use of REFRESH PUBLICATION in code and messages.

  10. Add "ALL SEQUENCES" support to publications.

  11. Expose sequence page LSN via pg_get_sequence_data.

  12. Resume conflict-relevant data retention automatically.

  13. Post-commit review fixes for 228c370868.

  14. Generate GUC tables from .dat file

Attachments

On Wed, 9 Jul 2025 at 14:12, shveta malik <shveta.malik@gmail.com> wrote:
>
> Please find a few more comments on July4 patch
>
> 6)
> +  <para>
> +   To synchronize sequences from a publisher to a subscriber, first publish
> +   them using <link linkend="sql-createpublication-params-for-all-sequences">
> +   <command>CREATE PUBLICATION ... FOR ALL SEQUENCES</command></link>.
> +  </para>
>
> This sentence looks odd, as we have 'first' but no follow-up sentence
> after that. Can we please combine this line with the next one in the
> doc saying:
>
> To synchronize sequences from a publisher to a subscriber, first
> publish them using CREATE PUBLICATION ... FOR ALL SEQUENCES and then
> at the subscriber side:

Modified

> 7)
>
> +         <para>
> +          This parameter is not applicable for sequences.
> +         </para>
>
> It is mentioned 3 times in doc for publish, publish_generated_columns
> and publish_via_partition_root. Instead shall we mention it once for
> WITH-clause itself. Something like:
>
> This clause specifies optional parameters for a publication when
> publishing tables. This clause is not applicable for sequences.

Modified

> 8)
> +   The view <structname>pg_publication_sequences</structname> provides
> +   information about the mapping between publications and information of
> +   sequences they contain.
>
> Why not:
> "The view pg_publication_sequences provides information about the
> mapping between publications and sequences."
>
> I think the existing detail has been written similar to
> 'pg_publication_tables' doc. But there, 'information of tables' made
> sense as pg_publication_tables has attnames and rowfilters  too. But
> pg_publication_sequences OTOH just has
> the mapping between names. No other information.

Modified

> 9)
> +  <sect2 id="sequence-definition-mismatches">
> +   <title>Sequence Definition Mismatches</title>
> +   <warning>
> +    <para>
> +     During sequence synchronization, the sequence definitions of the publisher
> +     and the subscriber are compared.
>
> Now in code, we give WARNING for missing sequences on publisher as
> well. Do we need to mention that here? IIUC, this WARNING for missing
> sequences can come only if the worker is respawned to sync
> unmatched/failed sequences and meanwhile any one of failed sequences
> is dropped on publisher. But it will be good to mention it briefly in
> doc.

Modified

Also the comment from [1] is handled.
The attached v20250711 version patch has the changes for the same.

[1] - https://www.postgresql.org/message-id/CABdArM640YF7MQfMVhEX%3De1pJdrnVcCwS_y4XXsbvah%3D6P9S%3DA%40mail.gmail.com

Regards,
Vignesh