Luca Ferrari <fluca1978@xxxxxxxxx> writes: > On Wed, Feb 27, 2019 at 12:33 PM Julien Rouhaud <rjuju123@xxxxxxxxx> 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
