Re: incorrect handling of the timeout in pg_receivexlog

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.

> 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.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com