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

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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Next
From: "Joshua D. Drake"
Date:
Subject: Re: s/recovery_connections/allow_standby_queries/, or something like that?