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