Prev: s/recovery_connections/allow_standby_queries/, or something like that?
Next: pgsql: Make CheckRequiredParameterValues()depend upon correct
From: Heikki Linnakangas on 29 Apr 2010 13:38 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 29 Apr 2010 14:11
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 |