On Fri, Feb 15, 2013 at 12:12:03PM -0500, Bruce Momjian wrote:
> On Thu, Feb 14, 2013 at 07:21:27PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Agreed. The attached patch modifies pg_check_dir() to report about
> > > invisible and lost+found directory entries, and give more helpful
> >
On Thu, Feb 14, 2013 at 07:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. The attached patch modifies pg_check_dir() to report about
> > invisible and lost+found directory entries, and give more helpful
> > messages to the user.
>
> I'm not terribly thrilled with special-casi
On Thu, Feb 14, 2013 at 07:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. The attached patch modifies pg_check_dir() to report about
> > invisible and lost+found directory entries, and give more helpful
> > messages to the user.
>
> I'm not terribly thrilled with special-casi
Bruce Momjian writes:
> Agreed. The attached patch modifies pg_check_dir() to report about
> invisible and lost+found directory entries, and give more helpful
> messages to the user.
I'm not terribly thrilled with special-casing 'lost+found' like that,
since it's an extremely filesystem-dependen
On Tue, Feb 5, 2013 at 08:49:17AM -0500, Peter Eisentraut wrote:
> On 2/5/13 7:32 AM, Kevin Grittner wrote:
> > Sean Chittenden wrote:
> >
> >> > Currently src/port/pgcheckdir.c will reject non-empty
> >> > directories, which is an issue during initdb(1) when PGDATA is
> >> > also the mount poin
Sean Chittenden writes:
> I agree it's not ideal for some filesystems, but being overly protective
> doesn't buy us much either, because in some setups, it's entirely acceptable.
No, it isn't. As several people have told you already, the idea of
letting a mount point be used directly as a data
Sean Chittenden wrote:
> In thinking about it, I like ignoring the hidden directories and failing when
> lost+found is present
> because, IMO, filesystems where lost+found is going to be present are exactly
> the filesystems that
> shouldn't have PGDATA located at the top of a mount point.
Huh?
>> Currently src/port/pgcheckdir.c will reject non-empty
>> directories, which is an issue during initdb(1) when PGDATA is
>> also the mount point for filesystems that support snapshots (e.g.
>> ZFS or UFS2).
>
>> Granted it's not hard to create a subdirectory, initdb there and
>> move the content
On 5 February 2013 13:50, Craig Ringer wrote:
> On 02/05/2013 08:32 PM, Kevin Grittner wrote:
>
>> I would rather add a sentence or two to the
>> initdb documentation recommending that a cluster not be created at
>> a mount point; it should be created in a directory underneath the
>> mount point.
On 02/05/2013 08:32 PM, Kevin Grittner wrote:
> I would rather add a sentence or two to the
> initdb documentation recommending that a cluster not be created at
> a mount point; it should be created in a directory underneath the
> mount point.
That makes a great deal of sense, actually. There's no
On 2/5/13 7:32 AM, Kevin Grittner wrote:
> Sean Chittenden wrote:
>
>> > Currently src/port/pgcheckdir.c will reject non-empty
>> > directories, which is an issue during initdb(1) when PGDATA is
>> > also the mount point for filesystems that support snapshots (e.g.
>> > ZFS or UFS2).
>> > Granted
On 02/05/2013 07:32 AM, Kevin Grittner wrote:
Sean Chittenden wrote:
Currently src/port/pgcheckdir.c will reject non-empty
directories, which is an issue during initdb(1) when PGDATA is
also the mount point for filesystems that support snapshots (e.g.
ZFS or UFS2).
Granted it's not hard to cr
>> Hello. This was bounced my way via IRC[1] and I'm kicking an updated version
>> of the patch upstream for review and committing.
>>
>> Instead, it seems more correct to simply ignore all directories that begin
>> with a dot character. I'm not aware of any special directories exposed by
>> fi
Sean Chittenden wrote:
> Currently src/port/pgcheckdir.c will reject non-empty
> directories, which is an issue during initdb(1) when PGDATA is
> also the mount point for filesystems that support snapshots (e.g.
> ZFS or UFS2).
> Granted it's not hard to create a subdirectory, initdb there and
>
On 02/05/2013 04:36 PM, Sean Chittenden wrote:
> Hello. This was bounced my way via IRC[1] and I'm kicking an updated version
> of the patch upstream for review and committing.
>
> Instead, it seems more correct to simply ignore all directories that begin
> with a dot character. I'm not aware of
Hello. This was bounced my way via IRC[1] and I'm kicking an updated version of
the patch upstream for review and committing.
Currently src/port/pgcheckdir.c will reject non-empty directories, which is an
issue during initdb(1) when PGDATA is also the mount point for filesystems that
support sn
16 matches
Mail list logo
