Re: why not using a mountpoint as PGDATA?

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: why not using a mountpoint as PGDATA?
Дата
Msg-id 20190227150123.3iqcpznczqoxlma5@hjp.at
обсуждение исходный текст
Ответ на Re: why not using a mountpoint as PGDATA?  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: why not using a mountpoint as PGDATA?  (raf@raf.org)
Список 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/>

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: idle_in_transaction_session_timeout for a set of SQL statements
Следующее
От: Edson Carlos Ericksson Richter
Дата:
Сообщение: Re: Barman disaster recovery solution