Luca Ferrari <fluca1978@gmail.com> writes:
> On Wed, Feb 27, 2019 at 12:33 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>> You can see most obvious reasons at
>> https://bugzilla.redhat.com/show_bug.cgi?id=1247477
> Thanks, I didn't see the lost+found problem because I'm on UFS (I'm
> wondering if this applies also to ZFS datasetes with mount point).
> Same story for the accidentally umount, since FreeBSD seems enough
> friendly to avoid umount while the database is running, but it could
> definetely happen with some brute force or on another operating
> system.
The case that I can recall most clearly was actually in the other
direction: during system bootup, some NFS volume that was being abused
this way (mount point == data dir) was slow to mount. Compounding the
problem, postgres was being started through some init script that would
helpfully run initdb if it saw the specified data directory was empty.
So, rather than failing like a properly paranoid DBA would wish, it
ran initdb and then started the postmaster. A bit later, the NFS volume
came online, replacing the mount-point directory, and now the postmaster
had a devil's brew of open files on the local volume containing the mount
point and open files on the NFS volume. It didn't take long for that to
translate into hopeless catalog corruption. I don't think they ever got
their data back.
The true value of data-dir-at-least-one-level-down is so that it will
fail to be there at all if the file system isn't mounted. You need that,
and you do *not* want automated attempts to "repair" that.
regards, tom lane
