From: Heikki Linnakangas on
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

--
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: Heikki Linnakangas on
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

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