Re: Replication & recovery_min_apply_delay
От | Michael Paquier |
---|---|
Тема | Re: Replication & recovery_min_apply_delay |
Дата | |
Msg-id | 20190802054435.GE1717@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Replication & recovery_min_apply_delay (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Replication & recovery_min_apply_delay
|
Список | pgsql-hackers |
On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote: > As for the test module, the one I submitted takes a lot of time to run > (well, 60s) and I don't think it's a good idea to include it as > something to be run all the time by every buildfarm member. I'm not > sure that there's a leaner way to test for this bug, though, but > certainly it'd be a good idea to ensure that this continues to work. Hmmm. Instead of that, wouldn't it be cleaner to maintain in the context of the startup process a marker similar to receivedUpto for the last LSN? The issue with this one is that it gets reset easily so we would lose track of it easily, and we need also to count with the case where a WAL receiver is not started. So I think that we should do that as a last replayed or received LSN if a WAL receiver is up and running, whichever is newer. Splitting the WAL receiver restart logic into a separate routine is a good idea in itself, the patch attempting to switch primary_conninfo to be reloadable could make use of that. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: