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 15589.1432871753@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:
>> 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.

Will look at that tomorrow ...

> 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.

Actually, I was seriously considering removing the don't-log-EACCES
special case (at least for files, perhaps not for directories).
The reason being that it's darn hard to verify that the code is doing
what it's supposed to when there is no simple way to get it to log any
complaints.  I left it as you wrote it in the committed version, but
I think both that and the ETXTBSY special case do not really have value
as long as their only effect is to suppress a LOG entry.

Speaking of which, could somebody test that the committed patch does
what it's supposed to on Windows?  You were worried upthread about
whether the tests for symlinks (aka junction points) behaved correctly,
and I have no way to check that either.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: useless assignment pointer argument
Next
From: Oskari Saarenmaa
Date:
Subject: Re: hstore_plpython regression test does not work on Python 3