Обсуждение: pgsql: Adjust initdb to also not consider fsync'ing failures fatal.
Adjust initdb to also not consider fsync'ing failures fatal. Make initdb's version of this logic look as much like the backend's as possible. This is much less critical than in the backend since not so many people use "initdb -S", but we want the same corner-case error handling in both cases. Back-patch to 9.3 where initdb -S option was introduced. Before that, initdb only had to deal with freshly-created data directories, wherein no failures should be expected. Abhijit Menon-Sen Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/c07d8c963e39980f192e8daca73b7585ef76cc9b Modified Files -------------- src/bin/initdb/initdb.c | 306 ++++++++++++++++++++++++----------------------- 1 file changed, 155 insertions(+), 151 deletions(-)
On 5/29/15 1:05 PM, Tom Lane wrote:
> Adjust initdb to also not consider fsync'ing failures fatal.
This introduces a failure in the initdb tests, which expect that
initdb -S -D /notthere
returns a nonzero exit code.
The output of that command is also a bit crazy now:
$ pg-install/bin/initdb -S -D /notthere
syncing data to disk ... initdb: could not stat file
"/notthere/pg_xlog": No such file or directory
initdb: could not open directory "/notthere": No such file or directory
initdb: could not open directory "/notthere/pg_tblspc": No such file or
directory
ok
I think the behavior to ignore fsync failures should probably not apply
to top-level directories. Or alternatively, the existence of these
directories should be checked separately.
Peter Eisentraut <peter_e@gmx.net> writes:
> On 5/29/15 1:05 PM, Tom Lane wrote:
>> Adjust initdb to also not consider fsync'ing failures fatal.
> This introduces a failure in the initdb tests, which expect that
> initdb -S -D /notthere
> returns a nonzero exit code.
Hm, I guess we don't run anything else that touches the DB directory
in this case? In the backend case we'd have failed much earlier.
I'm not 100% convinced that the test case's expectation is necessarily
the right thing, though.
regards, tom lane
On 5/29/15 4:06 PM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On 5/29/15 1:05 PM, Tom Lane wrote:
>>> Adjust initdb to also not consider fsync'ing failures fatal.
>
>> This introduces a failure in the initdb tests, which expect that
>> initdb -S -D /notthere
>> returns a nonzero exit code.
>
> Hm, I guess we don't run anything else that touches the DB directory
> in this case? In the backend case we'd have failed much earlier.
Yeah, in the backend, there are various checks earlier that the data
directory exists.
> I'm not 100% convinced that the test case's expectation is necessarily
> the right thing, though.
Well, I think a tool
do_something DIRECTORY
that just prints out error messages and says "ok" without an error code
when the directory doesn't exist is a pretty crappy behavior.
The premise of this change was that we don't know what all the files in
the data directory might be, but we do know what the top-level directory
is, so we should treat that properly.