On 02/26/2017 12:55 AM, Robert Haas wrote: > On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs <si...@2ndquadrant.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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
