From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Date: | 2015-05-29 03:55:53 |
Message-ID: | 15589.1432871753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Oskari Saarenmaa | 2015-05-29 05:40:46 | Re: hstore_plpython regression test does not work on Python 3 |
Previous Message | Tom Lane | 2015-05-29 03:45:24 | Re: useless assignment pointer argument |