Thread: s/recovery_connections/allow_standby_queries/, or something like that?

I've just realized that one of the confusing things about this debate
is that the recovery_connections parameter is very confusingly named.
It might have been okay when HS existed in isolation, but with SR in the
mix, it's not at all clear that the parameter refers to client
connections made to a standby server, and not to replication connections
made from a standby to its master.  It is easy to think that this is a
parameter that needs to be turned on in the master to allow standby
slaves to connect to it.

Another problem is that it looks more like an integer parameter
(ie, maximum number of such connections) than a boolean.

I think a different name would help.  The best idea I can come up with
on the spur of the moment is "allow_standby_queries", but I'm not sure
that can't be improved on.  Comments?
        regards, tom lane

On Thu, Apr 29, 2010 at 1:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I've just realized that one of the confusing things about this debate
> is that the recovery_connections parameter is very confusingly named.
> It might have been okay when HS existed in isolation, but with SR in the
> mix, it's not at all clear that the parameter refers to client
> connections made to a standby server, and not to replication connections
> made from a standby to its master.  It is easy to think that this is a
> parameter that needs to be turned on in the master to allow standby
> slaves to connect to it.
>
> Another problem is that it looks more like an integer parameter
> (ie, maximum number of such connections) than a boolean.
>
> I think a different name would help.  The best idea I can come up with
> on the spur of the moment is "allow_standby_queries", but I'm not sure
> that can't be improved on.  Comments?

I agree that name is better.  It would also be nice if the name of
that GUC matched the value that must be set for wal_level as closely
as possible.

...Robert

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It is easy to think that this is a parameter that needs to be
> turned on in the master to allow standby slaves to connect to it.
> I think a different name would help.
Yeah, I had to double-check because the current name wasn't, in
itself, unambiguous.  We'd be sure to get many posts from confused
users on this if we don't rename it.
> The best idea I can come up with on the spur of the moment is
> "allow_standby_queries", but I'm not sure that can't be improved
> on.
That seems clear and self-explanatory to me.
-Kevin

Tom Lane wrote:
> I think a different name would help.  The best idea I can come up with
> on the spur of the moment is "allow_standby_queries", but I'm not sure
> that can't be improved on.  Comments?

One objection to that name is that it also works during archive
recovery, like during PITR, which is not a standby server.  But that's
probably a rare use case.

+1 on changing it to something.

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

On Thu, Apr 29, 2010 at 1:38 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Tom Lane wrote:
>> I think a different name would help.  The best idea I can come up with
>> on the spur of the moment is "allow_standby_queries", but I'm not sure
>> that can't be improved on.  Comments?
>
> One objection to that name is that it also works during archive
> recovery, like during PITR, which is not a standby server.  But that's
> probably a rare use case.

Gee, I think of it as a standby regardless of whether it's created
using archiving or SR.  Do we not have a generic term that covers both
cases?

> +1 on changing it to something.

Boy, my blog post is going to have a darn short shelf life (see the
last paragraph).

http://rhaas.blogspot.com/2010/04/write-ahead-logging-in-postgresql-90.html

...Robert

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> I think a different name would help.  The best idea I can come up with
>> on the spur of the moment is "allow_standby_queries", but I'm not sure
>> that can't be improved on.  Comments?

> One objection to that name is that it also works during archive
> recovery, like during PITR, which is not a standby server.  But that's
> probably a rare use case.

Huh, that is an interesting point.  I think it might eventually be a
common use case: when you're trying to determine where to stop a PITR
recovery, it would be really nice to be able to roll forward to some
point, pause the recovery, and then snoop around in the database in
a read-only fashion before deciding whether to advance further.  We
don't currently have a good mechanism for the pause-and-resume bit
but I bet something like walreceiver could be built to do that.
The "snoop around" part is already handled nicely by HS.

> +1 on changing it to something.

Any thoughts on what?
        regards, tom lane

On Thu, 2010-04-29 at 13:18 -0400, Tom Lane wrote:
> I've just realized that one of the confusing things about this debate
> is that the recovery_connections parameter is very confusingly named.
> It might have been okay when HS existed in isolation, but with SR in the
> mix, it's not at all clear that the parameter refers to client
> connections made to a standby server, and not to replication connections
> made from a standby to its master.  It is easy to think that this is a
> parameter that needs to be turned on in the master to allow standby
> slaves to connect to it.
>
> Another problem is that it looks more like an integer parameter
> (ie, maximum number of such connections) than a boolean.
>
> I think a different name would help.  The best idea I can come up with
> on the spur of the moment is "allow_standby_queries", but I'm not sure
> that can't be improved on.  Comments?

enable_standby_queries (nitpicky but it seems more appropriate)

Joshua D. Drake


>
>             regards, tom lane
>


--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering

Tom Lane wrote:
> Huh, that is an interesting point.  I think it might eventually be a
> common use case: when you're trying to determine where to stop a PITR
> recovery, it would be really nice to be able to roll forward to some
> point, pause the recovery, and then snoop around in the database in
> a read-only fashion before deciding whether to advance further.  We
> don't currently have a good mechanism for the pause-and-resume bit
> but I bet something like walreceiver could be built to do that.
> The "snoop around" part is already handled nicely by HS.

Yeah, it's too bad we never got around to fix the pause/resume functions
the original HS patch included.

>> +1 on changing it to something.
> 
> Any thoughts on what?

Well, the obvious possibility is:
hot_standby = on/off

allow_recovery_queries? Not sure I like either of those more than
allow_standby_queries, though, despite what I just wrote.

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

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> +1 on changing it to something.
>> 
>> Any thoughts on what?

> Well, the obvious possibility is:
> hot_standby = on/off

> allow_recovery_queries? Not sure I like either of those more than
> allow_standby_queries, though, despite what I just wrote.

I don't think we want the word "recovery" in there at all.  From the
standpoint of system internals it might make sense, but the user is
not going to think of a hot standby server as being "in recovery".

I could go with just plain "hot_standby", though.  It's sensible
and it also fits Robert's suggestion that it should match up with
the corresponding wal_level setting.
        regards, tom lane

On Thu, 2010-04-29 at 13:18 -0400, Tom Lane wrote:
> I've just realized that one of the confusing things about this debate
> is that the recovery_connections parameter is very confusingly named.
> It might have been okay when HS existed in isolation, but with SR in the
> mix, it's not at all clear that the parameter refers to client
> connections made to a standby server, and not to replication connections
> made from a standby to its master.  It is easy to think that this is a
> parameter that needs to be turned on in the master to allow standby
> slaves to connect to it.
> 
> Another problem is that it looks more like an integer parameter
> (ie, maximum number of such connections) than a boolean.
> 
> I think a different name would help.  The best idea I can come up with
> on the spur of the moment is "allow_standby_queries", but I'm not sure
> that can't be improved on.  Comments?

enable_standby_queries (nitpicky but it seems more appropriate) 

Joshua D. Drake


> 
>             regards, tom lane
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering