Re: [PATCH] initdb: do not exit after warn_on_mount_point - Mailing list pgsql-hackers
From | andrey.arapov@nixaid.com |
---|---|
Subject | Re: [PATCH] initdb: do not exit after warn_on_mount_point |
Date | |
Msg-id | 900fd89f8910b1862a6ac90996f09318@nixaid.com Whole thread Raw |
In response to | Re: [PATCH] initdb: do not exit after warn_on_mount_point (Julien Rouhaud <rjuju123@gmail.com>) |
List | pgsql-hackers |
September 11, 2022 12:18 PM, "Julien Rouhaud" <rjuju123@gmail.com> wrote: > Hi, > > On Sat, Sep 10, 2022 at 07:14:59PM +0000, andrey.arapov@nixaid.com wrote: > >> Have slightly improved the logic so that it does not report an error >> "directory \"%s\" exists but is not empty" >> when it is only supposed to warn the user about the mountpoint, without >> exiting. >> >> To me, my patch looks like a typo fix where exit(1) should not be called on >> the warn_on_mount_point(), but only warn and continue as more people are >> mounting the device at `/var/lib/postgresql/data` (PGDATA) in the >> containerized world (K8s deployments, especially now in the Akash Network I >> am working for) for making sure their data persist. > > This definitely isn't a typo, as it's really strongly discouraged to use a > mount point for the data directory. You can refer to this thread [1] for more > explanations. > > [1] > https://www.postgresql.org/message-id/flat/CAKoxK+6H40imynM5P31bf0DnpN-5f5zeROjcaj6BKVAjxdEA9w@mail. > mail.com I've read the "why not using a mountpoint as PGDATA?" thread [1] as well as Bugzilla "postgresql-setup fails when /var/lib/pgsql/datais mount point" thead [2] but could not find any good reason why not to mount the PGDATA directly, except probably for the NFS mount point, but who does that anyway? And using NFS for PostgreSQL PGDATA is a way for finding problems starting with poor performance ending up with corruptedDB. lol The only point that hooked my attention was the pg_upgrade, but then I've tried pg_upgrade'ing postgresql:13 to postgresql:14,everything went without issues. I wrote a step-by-step doc for that purpose [3]. That leaves me unconvinced on why would `initdb` quit when detecting PGDATA being a mountpoint. Everyone using containerized postgresql image cannot use /var/lib/postgresql as the mountpoint but has to use /var/lib/postgresql/datainstead due to this issue [4] due to [5]. Hence, everyone using containerized version of postgresql with the device (say Ceph's RBD) mounted over /var/lib/postgresql/datadirectory has to either specify: - PGDATA=/var/lib/postgresql/data/<some-dir> OR make sure to remove $PGDATA/lost+found directory. Both of these hacks are only for the initdb to fail detect the mountpoint which, on its own, is supposed to be only a warningwhich is seen from the function name warn_on_mount_point() and its messages [6] look to be of only advisory natureto me. I would understand initdb to exit if it detects the mountpoint being is NFS, otherwise, there is no reason for not lettingone use the mountpoint over PGDATA as neither it breaks the pg_upgrade functionality as shown in this message. [1] https://www.postgresql.org/message-id/flat/CAKoxK+6H40imynM5P31bf0DnpN-5f5zeROjcaj6BKVAjxdEA9w@mail.gmail.com [2] https://bugzilla.redhat.com/show_bug.cgi?id=1247477 [3] https://gist.github.com/andy108369/aa3bf1707054542f2fa944f6d39aef64 [4] https://github.com/docker-library/postgres/issues/404#issuecomment-773755801 [5] https://github.com/docker-library/postgres/blob/3c20b7bdb915ecb1648fb468ab53080c58bb1716/Dockerfile-debian.template#L184 [6] https://github.com/postgres/postgres/blob/7fed801135bae14d63b11ee4a10f6083767046d8/src/bin/initdb/initdb.c#L2616-L2626 Kind regards, Andrey Arapov
pgsql-hackers by date: