Re: fsync-pgdata-on-recovery tries to write to more files than previously - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id 9975.1432919658@sss.pgh.pa.us
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: fsync-pgdata-on-recovery tries to write to more files than previously
Re: fsync-pgdata-on-recovery tries to write to more files than previously
List pgsql-hackers
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> At 2015-05-28 17:37:16 -0400, tgl@sss.pgh.pa.us wrote:
>> I have to leave shortly, so I'll look at the initdb cleanup tomorrow.

> Here's a revision of that patch that's more along the lines of what you
> committed.

Pushed with minor revisions.

> It occurred to me that we should probably also silently skip EACCES on
> opendir and stat/lstat in walkdir. That's what the attached initdb patch
> does. If you think it's a good idea, there's also a small fixup attached
> for the backend version too.

As I mentioned yesterday, I'm not really on board with ignoring EACCES,
except for the directories-on-Windows case.  Since we're only logging
the failures anyway, I think it is reasonable to log a complaint for any
unwritable file in the data directory.  I've not done it yet, but what
I think we oughta do is revert
if (errno == EACCES || (isdir && errno == EISDIR))

back to the former logic
if (isdir && (errno == EISDIR || errno == EACCES))

and even then, maybe the EACCES exclusion ought to be Windows only?

Also I want to get rid of the ETXTBSY special cases.  That one doesn't
seem like something that we should silently ignore: what the heck are
executables doing in the data directory?  Or is there some other meaning
on Windows?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [Proposal] More Vacuum Statistics
Next
From: Josh Berkus
Date:
Subject: Need Force flag for pg_drop_replication_slot()