Re: unite recovery.conf and postgresql.conf

From: Joshua Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-09-16 19:22:53
Message-ID: 1178268890.215818.1316200973038.JavaMail.root@mail-1.01.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> I'm in favor of defining a separate, content-free trigger file to
> enable
> archive recovery. Not sure about the name "recovery.ready", though
> ---
> that makes it look like one of the WAL archive transfer trigger
> files,
> which does not seem like a great analogy. The pg_standby
> documentation
> suggests names like "foo.trigger" for failover triggers, which is a
> bit
> better analogy because something external to the database creates the
> file. What about "recovery.trigger"?

Do we want a trigger file to enable recovery, or one to *disable* recovery? Or both?

Also, I might point out that we're really confusing our users by talking about "recovery" all the time, if they're just using streaming replication. Just sayin'

> * will seeing these values present in pg_settings confuse anybody?

No. pg_settings already has a couple dozen "developer" parameters which nobody not on this mailing list understands. Adding the recovery parameters to it wouldn't confuse anyone further, and would have the advantage of making the recovery parameters available by monitoring query on a hot standby.

For that matter, I'd suggest that we add a read-only setting called in_recovery.

> * can the values be changed when not in recovery, if so what happens,
> and again will that confuse anybody?

Yes, and no.

> * is there any security hazard from ordinary users being able to see
> what settings had been used?

primary_conninfo could be a problem, since it's possible to set a password there.

--Josh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Benjamin LaHaise 2011-09-16 20:08:17 Re: Improve lseek scalability v3
Previous Message Tom Lane 2011-09-16 18:51:11 Re: SSI heap_insert and page-level predicate locks