Prev: Choosing between seqscan and bitmap scan
Next: s/recovery_connections/allow_standby_queries/, or somethinglike that?
From: Robert Haas on 29 Apr 2010 13:21
On Thu, Apr 29, 2010 at 1:18 PM, Tom Lane <tgl(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on 29 Apr 2010 13:28
Tom Lane <tgl(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 29 Apr 2010 13:49
Heikki Linnakangas <heikki.linnakangas(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 29 Apr 2010 14:33
Heikki Linnakangas <heikki.linnakangas(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Choosing between seqscan and bitmap scan
Next: s/recovery_connections/allow_standby_queries/, or somethinglike that?