Re: incorrect handling of the timeout in pg_receivexlog

On Tue, Feb 7, 2012 at 10:55, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 07.02.2012 11:35, Magnus Hagander wrote:
>>
>> On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>
>>> So, --statusint needs to be in milliseconds. And while we're at it, how
>>>
>>> difficult would be to ask the server for the current value of
>>> replication_timeout, and set --statusint automatically based on that? Or
>>> perhaps mark replication_timeout as GUC_REPORT. It is rather fiddly that
>>> depending on a server setting, you need to pass an option in the client
>>> or
>>> it will just silently fail with no indication of what the problem is.
>>
>>
>> We can't really ask for it easily, since we're on a replication
>> connection. Unless we add that to the walsender grammar, but that
>> would make it impossible to use the receivexlog stuff against a 9.1
>> server (which I think still works, though I haven't tested it in a
>> while).
>
>
> You could put a version-check there, and only send the command if connected
> to a 9.2 server.

True..

>> Do we have a facility to make it a GUC_REPORT but only for walsender
>> connections?
>
>
> There's no such facility at the moment.
>
>
>> It seems like a very unnecessary thing to have it sent out over every
>> single connection, since it would only be useful in a very small
>> subset of them.
>
>
> True, and conversely, many of the current GUC_REPORT settings don't apply to
> replication clients at all. Like standard_conforming_strings and DateStyle.

Right. But it's less important there, since the replication
connections will in any reasonable configuration be only a tiny part
of the connections.

> I think we need another flag for settings that should be sent to replication
> clients. GUC_REPORT_REPLICATION? Some settings would have both GUC_REPORT
> and GUC_REPORT_REPLICATION, while others would have only one of them.

Yup, seems like the cleanest solution.

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