Re: Replication & recovery_min_apply_delay
От | Alvaro Herrera |
---|---|
Тема | Re: Replication & recovery_min_apply_delay |
Дата | |
Msg-id | 20190731204326.GA5625@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Replication & recovery_min_apply_delay (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: Replication & recovery_min_apply_delay
|
Список | pgsql-hackers |
On 2019-Jul-31, Konstantin Knizhnik wrote: > On 08.07.2019 11:05, Michael Paquier wrote: > > Please note that I have not looked at that stuff in details, but I > > find the patch proposed kind of ugly with the scan of the last segment > > using a WAL reader to find out what is the last LSN and react on > > that.. This does not feel right. > > I am sorry for delay with answer. > Looks like I have not noticed your reply:( > Can you explain me please why it is not correct to iterate through WAL using > WAL reader to get last LSN? I agree that it's conceptually ugly, but as I mentioned in my previous reply, I tried several other strategies before giving up and ended up concluding that this way was a good way to solve the problem. I don't endorse the exact patch submitted, though. I think it should have a lot more commentary on what the code is doing and why. 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. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: