RE: How can end users know the cause of LR slot sync delays?
| От | Hayato Kuroda (Fujitsu) |
|---|---|
| Тема | RE: How can end users know the cause of LR slot sync delays? |
| Дата | |
| Msg-id | OSCPR01MB14966FE0BFB6C212298BFFEDEF5D1A@OSCPR01MB14966.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | RE: How can end users know the cause of LR slot sync delays? ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
| Ответы |
RE: How can end users know the cause of LR slot sync delays?
|
| Список | 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 по дате отправления: