Re: incorrect handling of the timeout in pg_receivexlog

On Tue, Jun 5, 2012 at 4:28 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander <magnus(at)hagander(dot)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?

Works for me. We still need a (reworked) patch, though, right? We just
move where the move between seconds and milliseconds happens?

I definitely don't think we need subsecond granularity in the user
facing number. Even a second is pretty short. (We do need to retain
the ability to set it to 0 = off of course).

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/