RE: How can end users know the cause of LR slot sync delays?

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Shlok Kyal' <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Subject: RE: How can end users know the cause of LR slot sync delays?
Date: 2025-10-01 02:56:30
Message-ID: OSCPR01MB149667E5CFDD8F2A3DB7801D2F5E6A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Shlok,

> Thanks for updating the patch. Here are my comments.

I found one more comment.

```
+ /*
+ * If found_consistent_snapshot is not NULL and a consistent snapshot is
+ * found set the slot sync skip reason to none. Else, if consistent
+ * snapshot is not found the stats will be updated in the function
+ * update_and_persist_local_synced_slot
+ */
+ if (!found_consistent_snapshot || *found_consistent_snapshot)
+ update_slot_sync_skip_stats(slot, SS_SKIP_NONE);
```

I think the condition is confusing; in code level there is a path that
found_consistent_snapshot is NULL but synchronization happened. (Not sure it is
possible though).

I think it is better to put update_slot_sync_skip_stats() near the sync part.
If the snapshot exists from the beginning, it can be done unconditionally,
otherwise we can check again. Attached .diffs file implements it.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
kuroda.diffs application/octet-stream 1.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-10-01 03:04:54 Re: bug, ALTER TABLE call ATPostAlterTypeCleanup twice for the same relation
Previous Message Peter Smith 2025-10-01 02:29:56 pg_createsubscriber --dry-run logging concerns