Re: why not using a mountpoint as PGDATA? - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: why not using a mountpoint as PGDATA?
Date
Msg-id 20190227150123.3iqcpznczqoxlma5@hjp.at
Whole thread Raw
In response to Re: why not using a mountpoint as PGDATA?  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: why not using a mountpoint as PGDATA?  (raf@raf.org)
List pgsql-general
On 2019-02-27 12:33:02 +0100, Julien Rouhaud wrote:
> On Wed, Feb 27, 2019 at 12:22 PM Luca Ferrari <fluca1978@gmail.com> wrote:
> >
> > What's wrong with using a mountpoint?
>
> You can see most obvious reasons at
> https://bugzilla.redhat.com/show_bug.cgi?id=1247477

I see only one good reason there: The fact that pg_upgrade needs write
access to the parent directory. Of course that alone might suffice.

The other reasons aren't good IMHO.

The first one (initdb checks for an empty directory) is more "We
disallow it, therefore it is a bad idea" than a reason for disallowing
it.

The second is just wrong: You can have a non-root owned mount-point on
any Unixoid system I've worked with. (And I don't see why that would be
a security problem)

The third is wrong at least on Debian: All server processes have
/var/lib/postgresql/$version/$cluster as their working directory, so it
cannot be unmounted while the database is up. Even if you could, the
server would either immediately lose access to all files (in which case
you could recover) or it would keep access to all files (so, not a
problem). Plus being in a subdirectory wouldn't change that. Maybe it's
a potential problem with other layouts.

        hp

--
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

Attachment

pgsql-general by date:

Previous
From: Jeremy Finzel
Date:
Subject: idle_in_transaction_session_timeout for a set of SQL statements
Next
From: Edson Carlos Ericksson Richter
Date:
Subject: Re: Barman disaster recovery solution