Re: incorrect handling of the timeout in pg_receivexlog

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?

Regards,

--
Fujii Masao