Re: Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN
От | Andres Freund |
---|---|
Тема | Re: Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN |
Дата | |
Msg-id | 20230725170319.h423jbthfohwgnf7@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN
|
Список | pgsql-hackers |
Hi, On 2023-07-25 14:31:00 +0530, Amit Kapila wrote: > To ensure that all the data has been sent during the upgrade, we can > ensure that each logical slot's confirmed_flush_lsn (position in the > WAL till which subscriber has confirmed that it has applied the WAL) > is the same as current_wal_insert_lsn. Now, because we don't send > XLOG_CHECKPOINT_SHUTDOWN even on clean shutdown, confirmed_flush_lsn > will never be the same as current_wal_insert_lsn. The one idea being > discussed in patch [1] (see 0003) is to ensure that each slot's LSN is > exactly XLOG_CHECKPOINT_SHUTDOWN ago which probably has some drawbacks > like what if we tomorrow add some other WAL in the shutdown checkpoint > path or the size of record changes then we would need to modify the > corresponding code in upgrade. Yea, that doesn't seem like a good path. But there is a variant that seems better: We could just scan the end of the WAL for records that should have been streamed out? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: