On Wed, Jan 12, 2011 at 11:52 PM, Fujii Masao wrote:
> So I'm thinking to make ProcessConfigFile() parse not only postgresql.conf
> but also recovery.conf rather than move all the recovery parameters to
> postgresql.conf.
>
> Comments?
+1.
Actually moving the settings can be done later in about
On Wed, Dec 29, 2010 at 5:51 PM, Heikki Linnakangas
wrote:
> On 29.12.2010 10:36, Magnus Hagander wrote:
>>
>> On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
>>>
>>> Although maybe now that we've made recovery.conf use the GUC lexer we
>>> oughta continue in that vein and expose those paramet
Magnus Hagander writes:
> On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
>> Although maybe now that we've made recovery.conf use the GUC lexer we
>>oughta continue in that vein and expose those parameters as
>>PGC_INTERNAL GUCs rather than inventing a new function for it...
>
> That's definite
On 29.12.2010 10:36, Magnus Hagander wrote:
On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
Although maybe now that we've made recovery.conf use the GUC lexer we oughta
continue in that vein and expose those parameters as PGC_INTERNAL GUCs rather
than inventing a new function for it...
On Tue, Dec 28, 2010 at 18:12, Robert Haas wrote:
> On Dec 28, 2010, at 10:34 AM, Tom Lane wrote:
>> I'm still wondering what's the actual use-case for exposing this inside
>> SQL. Those with a legitimate need-to-know can look at the slave
>> server's config files, no?
>
> SQL access is frequent
On Tue, Dec 28, 2010 at 17:43, Guillaume Lelarge wrote:
> Le 28/12/2010 17:36, Tom Lane a écrit :
>> Guillaume Lelarge writes:
>>> Le 28/12/2010 16:34, Tom Lane a écrit :
>> 1. It'll have to be restricted to superusers, therefore ordinary
>> users on the slave can't actually make use of it.
>>
>
On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas
> wrote:
> >> SQL access is frequently more convenient, though. Although maybe now
> that
> >> we've made recovery.conf use the GUC lexer we oughta continue in that
> vein
Le 28/12/2010 19:30, Tom Lane a écrit :
> Gurjeet Singh writes:
>> On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas wrote:
>>> SQL access is frequently more convenient, though. Although maybe now that
>>> we've made recovery.conf use the GUC lexer we oughta continue in that vein
>>> and expose thos
Gurjeet Singh writes:
> On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas wrote:
>> SQL access is frequently more convenient, though. Although maybe now that
>> we've made recovery.conf use the GUC lexer we oughta continue in that vein
>> and expose those parameters as PGC_INTERNAL GUCs rather than
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas wrote:
> On Dec 28, 2010, at 10:34 AM, Tom Lane wrote:
> > I'm still wondering what's the actual use-case for exposing this inside
> > SQL. Those with a legitimate need-to-know can look at the slave
> > server's config files, no?
>
> SQL access is f
Le 28/12/2010 18:12, Robert Haas a écrit :
> On Dec 28, 2010, at 10:34 AM, Tom Lane wrote:
>> I'm still wondering what's the actual use-case for exposing this inside
>> SQL. Those with a legitimate need-to-know can look at the slave
>> server's config files, no?
>
> SQL access is frequently more
On Dec 28, 2010, at 10:34 AM, Tom Lane wrote:
> I'm still wondering what's the actual use-case for exposing this inside
> SQL. Those with a legitimate need-to-know can look at the slave
> server's config files, no?
SQL access is frequently more convenient, though. Although maybe now that
we've
Le 28/12/2010 17:50, Gurjeet Singh a écrit :
> On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane wrote:
>
>>
>> I can see the point of, say, a primary_host_address() function returning
>> inet, which would be way better on both those dimensions than the
>> current proposal. But I'm not sure what else w
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane wrote:
>
> I can see the point of, say, a primary_host_address() function returning
> inet, which would be way better on both those dimensions than the
> current proposal. But I'm not sure what else would be needed.
>
>
+1, since it bypasses security ri
Le 28/12/2010 17:36, Tom Lane a écrit :
> Guillaume Lelarge writes:
>> Le 28/12/2010 16:34, Tom Lane a écrit :
>>> I'm still wondering what's the actual use-case for exposing this inside
>>> SQL. Those with a legitimate need-to-know can look at the slave
>>> server's config files, no?
>
>> This
Guillaume Lelarge writes:
> Le 28/12/2010 16:34, Tom Lane a écrit :
>> I'm still wondering what's the actual use-case for exposing this inside
>> SQL. Those with a legitimate need-to-know can look at the slave
>> server's config files, no?
> This is something I wanted to have in 9.0 when I coded
Le 28/12/2010 16:34, Tom Lane a écrit :
> Magnus Hagander writes:
>> On Dec 28, 2010 3:58 PM, "Tom Lane" wrote:
>>> What's the use case? And aren't there security reasons to NOT expose
>>> that? It might contain a password for instance.
>
>> Good point - should be made superuser only.
>
> I'm
Magnus Hagander writes:
> On Dec 28, 2010 3:58 PM, "Tom Lane" wrote:
>> What's the use case? And aren't there security reasons to NOT expose
>> that? It might contain a password for instance.
> Good point - should be made superuser only.
I'm still wondering what's the actual use-case for expo
On Dec 28, 2010 3:58 PM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > Attached patch implements a function called pg_primary_conninfo() that
> > returns, well, the primary_conninfo used on the standby when in
> > streaming replication mode (otherwise NULL).
>
> > Objections?
>
> What's the u
Magnus Hagander writes:
> Attached patch implements a function called pg_primary_conninfo() that
> returns, well, the primary_conninfo used on the standby when in
> streaming replication mode (otherwise NULL).
> Objections?
What's the use case? And aren't there security reasons to NOT expose
th
On Tue, Dec 28, 2010 at 14:38, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander wrote:
>> Attached patch implements a function called pg_primary_conninfo() that
>> returns, well, the primary_conninfo used on the standby when in
>> streaming replication mode (otherwise NULL).
On Tue, Dec 28, 2010 at 8:31 AM, Magnus Hagander wrote:
> Attached patch implements a function called pg_primary_conninfo() that
> returns, well, the primary_conninfo used on the standby when in
> streaming replication mode (otherwise NULL).
+1. Let's make sure to explicitly document what this f
Attached patch implements a function called pg_primary_conninfo() that
returns, well, the primary_conninfo used on the standby when in
streaming replication mode (otherwise NULL).
Objections?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/doc/src/sg
23 matches
Mail list logo
