Re: fsync-pgdata-on-recovery tries to write to more files than previously

On Fri, May 29, 2015 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

The error can be reproduced by using junction
(https://technet.microsoft.com/en-us/sysinternals/bb896768.aspx) to
define a junction point within PGDATA and then for example mark as
read-only a configuration file included in postgresql.conf through the
junction point.

Using this method, I have checked that 9.4.1 works, reproduced the
permission error with 9.4.2, and checked as well that a3ae3db4 fixed
the problem. So things look to work fine.
Regards,
-- 
Michael