Re: incorrect handling of the timeout in pg_receivexlog
От | Fujii Masao |
---|---|
Тема | Re: incorrect handling of the timeout in pg_receivexlog |
Дата | |
Msg-id | CAHGQGwEaWuAX42uDXGk305NKsRtHXGLxvU_WaiDeRrfFAjy9iw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: incorrect handling of the timeout in pg_receivexlog (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: incorrect handling of the timeout in pg_receivexlog
|
Список | pgsql-hackers |
On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> You also removed the "safeguard" of always sleeping at least 1 second >>> - should we keep some level of safeguard there, even if it's not in >>> full seconds anymore? >>> >>> Is the -1 sent into localTimestampDifference still relevent at all? >> >> No because that "safeguard" would mess up with a user who sets >> replication_timeout to less than one second. Though I'm not sure >> whether there is really any user who wants such too short timeout.... > > Right - I meant we might want to adjust the safeguad. Assuming <1 sec > is reasonable, maybe cap it at 100ms or so? On second thought, the status packet interval doesn't need to be given in milliseconds at all. As I said, which would mess up with a user who sets replication_timeout to less than 1 sec. But since wal_receiver_status_interval is given in seconds, we've already messed up with them even if we've changed pg_receivexlog so that its status interval can be given in milliseconds. We received no complaints about wal_receiver_status_interval so far, so I think there is still no need to allow pg_receivexlog --statusint to be set to less than 1 sec. Thought? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: