Re: Proposal for changes to recovery.conf API

On 02/26/2017 12:55 AM, Robert Haas wrote:
> On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> I think the issue was that some people didn't want configuration files
>>> in the data directory. By removing recovery.conf we accomplish that.
>>> Signal/trigger files are not configuration (or at least it's much easier
>>> to argue that), so I think having them in the data directory is fine.
>>
>> There were a considerable number of people that pushed to make the
>> data directory non-user writable, which is where the signal directory
>> came from.
>
> Specifically, it's a problem for Debian's packaging conventions,
> right? The data directory can contain anything that the server itself
> will write, but configuration files that are written for the server to
> read are supposed to go in some external location dictated by Debian's
> packaging policy.
>
> Things like trigger files aren't configuration files per se, so maybe
> it's OK if those still get written into the data directory. Even if
> not, that seems like a separate patch. In my view, based on Michael's
> description of what the current patch version does, it's a clear step
> forward. Other steps can be taken at another time, if required.
>

From the perspective of containerized Postgres, you want config files to
go into one (non-writeable) directory, and anything which is writeable
by the DB server to go into another directory (and preferably, a single
directory).

A trigger file (that is, assuming an empty one, and recovery config
merged with pg.conf) would thus be writeable, non-configuration data
which goes in the data directory.

Users manually writing the trigger file doesn't show up as a problem
since, in a containerized environment, they can't. It's either written
by postgres itself, or by management software which runs as the postgres
user.

--
Josh Berkus
Containers & Databases Oh My!