Re: [PATCH] initdb: do not exit after warn_on_mount_point

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] initdb: do not exit after warn_on_mount_point
Дата
Msg-id 1390033.1662961891@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] initdb: do not exit after warn_on_mount_point  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: [PATCH] initdb: do not exit after warn_on_mount_point  (andrey.arapov@nixaid.com)
Список pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Sun, Sep 11, 2022 at 06:22:21PM +0000, andrey.arapov@nixaid.com wrote:
>> Everyone using containerized postgresql image cannot use /var/lib/postgresql
>> as the mountpoint but has to use /var/lib/postgresql/data instead due to this
>> issue [4] due to [5].

> initdb had this behavior for almost 10 years, and for good reasons: it prevents
> actual problems that were seen in the field.

The long and the short of this is that one person losing their data
outweighs thousands of people being very mildly inconvenienced by
having to create an extra level of directory.  I understand that you
don't think so, but you'd change your mind PDQ if it was *your* data
that got irretrievably corrupted.

We are not going to remove this check.

If anything, the fault I'd find with the existing code is that it's not
sufficiently thorough about detecting what is a mount point.  AFAICS,
neither the lost+found check nor the extra-dot-files check will trigger
on modern filesystems such as XFS.  I wonder if we could do something
like comparing the stat(2) st_dev numbers for the proposed data directory
vs. its parent directory.

            regards, tom lane



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: broken table formatting in psql
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Switching XLog source from archive to streaming when primary available