Re: s/recovery_connections/allow_standby_queries/, or something like that? - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: s/recovery_connections/allow_standby_queries/, or something like that?
Date
Msg-id 4BD9CBDF.7030107@enterprisedb.com
Whole thread Raw
In response to Re: s/recovery_connections/allow_standby_queries/, or something like that?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: s/recovery_connections/allow_standby_queries/, or something like that?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct