Обсуждение: 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
Re: s/recovery_connections/allow_standby_queries/, or something like that?
От
"Kevin Grittner"
Дата:
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
Re: s/recovery_connections/allow_standby_queries/, or something like that?
От
Heikki Linnakangas
Дата:
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
Re: s/recovery_connections/allow_standby_queries/, or something like that?
От
"Joshua D. Drake"
Дата:
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
Re: s/recovery_connections/allow_standby_queries/, or something like that?
От
Heikki Linnakangas
Дата:
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
Re: s/recovery_connections/allow_standby_queries/, orsomething like that?
От
"Joshua D. Drake"
Дата:
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