Re: Logical Replication of sequences - Mailing list pgsql-hackers

From Chao Li
Subject Re: Logical Replication of sequences
Date
Msg-id 598FC353-8E9A-4857-A125-740BE24DCBEB@gmail.com
Whole thread Raw
In response to Re: Logical Replication of sequences  (Chao Li <li.evan.chao@gmail.com>)
Responses RE: Logical Replication of sequences
List pgsql-hackers

> On Oct 17, 2025, at 17:34, Chao Li <li.evan.chao@gmail.com> wrote:
>
> I may find some time to review 0002 and 0003 next week.

I just reviewed 0002 and 0003. Got some comments for 0002, and no comment for 0003.


1 - 0002 - commit comment
```
Sequences have 3 states:
   - INIT (needs [re]synchronizing)
   - READY (is already synchronized)
```

3 states or 2 states? Missing DATASYNC?


2 - 0002 - launcher.c
```
+ * For both apply workers and sequence sync workers, the relid should be set to
+ * InvalidOid, as they manage changes across all tables and sequences. For table
+ * sync workers, the relid should be set to the OID of the relation being
+ * synchronized.
```

Nit: “both” sounds not necessarily.

3 - 0002 - launcher.c
```
  * Stop the logical replication worker for subid/relid, if any.
  */
 void
-logicalrep_worker_stop(Oid subid, Oid relid)
+logicalrep_worker_stop(Oid subid, Oid relid, LogicalRepWorkerType wtype)
```

Should the comment be updated? “subid/relid/wtype"

4 - 0002 - launcher.c
```
-    worker = logicalrep_worker_find(subid, relid, true);
+    worker = logicalrep_worker_find(subid, relid, WORKERTYPE_APPLY, true);
```

Based the comment you added to “logicalrep_worker_find()”, for apply worker, relid should be set to InvalidOid. (See
comment2) 

Then if you change this function to only work for WORKERTYPE_APPLY, relid should be hard code to InvalidOid, so that
“relid”can be removed from parameter list of logicalrep_worker_wakeup(). 

5 - 0002 - launcher.c
```
/*
* report_error_sequences
*
* Reports discrepancies in sequence data between the publisher and subscriber.
```

Nit: “Reports” -> “Report”

Here “reports” also work. But looking at the previous function’s comment:

```
 * Handle sequence synchronization cooperation from the apply worker.
*
* Start a sequencesync worker if one is not already running. The active
```

You used “handle” and “start” but “handles” and “starts”.

“Report” better matches imperative style in PG comments.

6 - 0002 - sequencesync.c
```
+report_error_sequences(StringInfo insuffperm_seqs, StringInfo mismatched_seqs)
+{
+    StringInfo    combined_error_detail = makeStringInfo();
+    StringInfo    combined_error_hint = makeStringInfo();
```

By the end of this function, I think we need to destroyStringInfo() these two strings.

7 - 0002 - sequencesync.c
```
+static void
+append_sequence_name(StringInfo buf, const char *nspname, const char *seqname,
+                     int *count)
+{
+    if (buf->len > 0)
+        appendStringInfoString(buf, ", “);
```

Why this “if” check is needed?

8 - 0002 - sequencesync.c
```
+        destroyStringInfo(seqstr);
+        destroyStringInfo(cmd);
```

Instead of making and destroying seqstr and cmd in every iteration, we can create them before “while”, and only
resetStringInfo()them for every iteration, which should be cheaper and faster. 

9 - 0002 - sequencesync.c
```
+    return h1 ^ h2;
+    /* XOR combine */
+}
```

This code is very descriptive, so the commend looks redundant. Also, why put the comment below the code line?

10 - 0002 - syncutils.c
```
 /*
- * Common code to fetch the up-to-date sync state info into the static lists.
+ * Common code to fetch the up-to-date sync state info for tables and sequences.
  *
- * Returns true if subscription has 1 or more tables, else false.
+ * The pg_subscription_rel catalog is shared by tables and sequences. Changes
+ * to either sequences or tables can affect the validity of relation states, so
+ * we identify non-ready tables and non-ready sequences together to ensure
+ * consistency.
  *
- * Note: If this function started the transaction (indicated by the parameter)
- * then it is the caller's responsibility to commit it.
+ * Returns true if subscription has 1 or more tables, else false.
  */
 bool
-FetchRelationStates(bool *started_tx)
+FetchRelationStates(bool *has_pending_sequences, bool *started_tx)
```
has_pending_sequences is not explained in the function comment.

11 - 0002 - syncutils.c
```
    /*
* has_subtables and has_subsequences is declared as static, since the
* same value can be used until the system table is invalidated.
*/
static bool has_subtables = false;
static bool has_subsequences_non_ready = false;
```

The comment says “has_subsequences”, but the real var name is “has_subsequences_non_ready".

12 - 0002 - syncutils.c
```
 bool
-FetchRelationStates(bool *started_tx)
+FetchRelationStates(bool *has_pending_sequences, bool *started_tx)
```

I searched over the code, this function has 3 callers, none of them want results for both table and sequence, so that a
caller,for example: 

```
bool
HasSubscriptionTablesCached(void)
{
bool started_tx;
bool has_subrels;
bool has_pending_sequences;

/* We need up-to-date subscription tables info here */
has_subrels = FetchRelationStates(&has_pending_sequences, &started_tx);

if (started_tx)
{
CommitTransactionCommand();
pgstat_report_stat(true);
}

return has_subrels;
}
```

Looks confused because it defines has_pending_sequences but not using it at all.

So, I think FetchRelationStates() can be refactored to return a result for either table or sequence, because on a type
parameter.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_restore --no-policies should not restore policies' comment
Next
From: Xuneng Zhou
Date:
Subject: Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array