Horton

Re: Logical Replication of sequences

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: vignesh C <vignesh21@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>, shveta malik <shveta.malik@gmail.com>
Date: 2025-07-03T09:37:16Z
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

Few more concerns:

4)
In UpdateSubscriptionRelState():
        if (!HeapTupleIsValid(tup))
                elog(ERROR, "subscription table %u in subscription %u
does not exist",
                         relid, subid);

table-->relation as now it can be hit for both sequence and table.

5)
In LogicalRepSyncSequences, why are we allocating it in a permanent
memory context?

+ /* Allocate the tracking info in a permanent memory context. */
+ oldctx = MemoryContextSwitchTo(CacheMemoryContext);
+ foreach_ptr(SubscriptionRelState, seq_state, sequences)
+ {
+ SubscriptionRelState *rstate = palloc(sizeof(SubscriptionRelState));
+
+ memcpy(rstate, seq_state, sizeof(SubscriptionRelState));
+ sequences_not_synced = lappend(sequences_not_synced, rstate);
+ }
+ MemoryContextSwitchTo(oldctx);

Same for 'seq_info' allocation.

6)
In LogicalRepSyncSequences, can you please help me understand this:
Why have we first created new list 'sequences_not_synced' from
'sequences' list, both have same elements of type
SubscriptionRelState; and then used that newly created
'sequences_not_synced list' to create remotesequences list having
element type LogicalRepSequenceInfo. Why didn't we use 'sequences'
list directly to create 'remotesequences' list?

7)
In this function we have 2 variables: seqinfo and seq_info. We are
using seqinfo to create seq_info. The names are very confusing.
Difficult to differentiate between the two.

In copy_sequences() too we have similarly named variables: seqinfo and
sequence_info.

Can we choose different names here?

8)
Why have we named argument of copy_sequences() as remotesequences?
IIUC, these are the sequences fetched from pg_subscription_rel and its
elements even maintain a field 'localrelid'. The name is thus
confusing as it has local data. Perhaps we can name it as
candidate_sequences or init_sequences (i.e. sequences in init state)
or any other suitable name.

thanks
Shveta