Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1J_PwsLduv9gfJn171ftOOgryRpLqSb7YGHKUKDZ_kZ2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
On Thu, Mar 28, 2024 at 3:34 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > On Thu, Mar 28, 2024 at 04:38:19AM +0000, Zhijie Hou (Fujitsu) wrote: > > > To fix this, we could use the fast forward logical decoding to advance the synced > > slot's lsn/xmin when syncing these values instead of directly updating the > > slot's info. This way, the snapshot will be serialized to disk when decoding. > > If we could not reach to the consistent point at the remote restart_lsn, the > > slot is marked as temp and will be persisted once it reaches the consistent > > point. I am still analyzing the fix and will share once ready. > > Thanks! I'm wondering about the performance impact (even in fast_forward mode), > might be worth to keep an eye on it. > True, we can consider performance but correctness should be a priority, and can we think of a better way to fix this issue? > Should we create a 17 open item [1]? > > [1]: https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items > Yes, we can do that. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: