On 07.02.2012 11:35, Magnus Hagander wrote:
On Tue, Feb 7, 2012 at 10:31, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
