RE: How can end users know the cause of LR slot sync delays? - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: How can end users know the cause of LR slot sync delays?
Date
Msg-id OSCPR01MB14966FE0BFB6C212298BFFEDEF5D1A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: How can end users know the cause of LR slot sync delays?  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses RE: How can end users know the cause of LR slot sync delays?
List pgsql-hackers
Dear Hou, Amit,

> Right, I agree. Here is the patch to release the slot at necessary places.

Thanks for working on it. However, BF machines have not satisfied the fix yet.
There are still two failures after 3df4df53b06 [1] [2].

The reported issue was that standby server failed to synchronize the slot after
the slot is re-created on the primary. According to [1], slots on standby has
newer catalog xmin than primary. Like:

```
LOG:  could not synchronize replication slot "lsub1_slot"
DETAIL:  Synchronization could lead to data loss, because the remote slot needs WAL at LSN 0/030163A8 and catalog xmin
758,but the standby has LSN 0/030163A8 and catalog xmin 759.
 
```

Per analysis, the newly created logical slot on primary has the initial catalog_xmin
as 758 due to the physical slot holding catalog_xmin:758. The standby does not
have slots, so the new slot will have the latest xid (759) as catalog_xmin.

Anyway, I think this is a test issue.

[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=scorpion&dt=2025-11-25%2009%3A03%3A17
[2]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grassquit&dt=2025-11-25%2009%3A01%3A08

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section
Next
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication