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