Re: Ignore lost+found when checking if a directory is empty - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Ignore lost+found when checking if a directory is empty
Date
Msg-id 1312922055-sup-9409@alvh.no-ip.org
Whole thread Raw
In response to Re: Ignore lost+found when checking if a directory is empty  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Ignore lost+found when checking if a directory is empty
List pgsql-hackers
Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011:
> On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote:
> > When an ext2, ext3, or ext4 filesystem is mounted directly on the
> > PGDATA directory, initdb will refuse to run because it sees the
> > lost+found directory that mke2fs created and assumes the PGDATA
> > directory is already in use for something other than PostgreSQL.
> > Attached is a patch against master which will cause a directory that
> > contains only lost+found to still be treated as empty.
> > 
> > This was previously proposed in 2001; see
> > http://archives.postgresql.org/pgsql-hackers/2001-03/msg01194.php
> 
> In the referenced discussion (10 years ago), Tom seemed OK with it and
> Peter did not seem to like it much.
> 
> I think I agree with Peter here that it's not a very good idea, and I
> don't see a big upside. With tablespaces it seems to make a little bit
> more sense, but I'd still lean away from that idea.

What if the init script tries to start postmaster before the filesystems
are mounted?  ISTM requiring a subdir is a good sanity check that the
system is ready to run.  Not creating stuff directly on the mountpoint
ensures consistency.

If you don't think this is a likely problem, search for Joe Conway's
report about a NFS share being unmounted for a while when postmaster was
started up, a couple of years ago.  Yes, it's rare.  Yes, it's real.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Next
From: Tom Lane
Date:
Subject: Re: augmenting MultiXacts to improve foreign keys