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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: andrey(dot)arapov(at)nixaid(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] initdb: do not exit after warn_on_mount_point
Date: 2022-09-12 05:51:31
Message-ID: 1390033.1662961891@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Sun, Sep 11, 2022 at 06:22:21PM +0000, andrey(dot)arapov(at)nixaid(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-09-12 06:26:29 Re: Switching XLog source from archive to streaming when primary available
Previous Message Pavel Stehule 2022-09-12 05:44:20 Re: broken table formatting in psql