Fix initdb misbehavior when user mis-enters superuser password.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 30 Aug 2016 19:25:01 +0000 (15:25 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 30 Aug 2016 19:25:01 +0000 (15:25 -0400)
commit37f6fd1eaab698983ca1fb2a036d52381347ac71
tree108854ea5123c1afc5f454d79d841fd791bbdbab
parent8e1e3f958fb3749fe01e9f2473f4554859c685a8
Fix initdb misbehavior when user mis-enters superuser password.

While testing simple_prompt() revisions, I happened to notice that
current initdb behaves rather badly when --pwprompt is specified and
the user miskeys the second password.  It complains about the mismatch,
does "rm -rf" on the data directory, and exits.  The problem is that
since commit c4a8812cf, there's a standalone backend sitting waiting
for commands at that point.  It gets unhappy about its datadir having
gone away, and spews a PANIC message at the user, which is not nice.
(And the shell then adds to the mess with meaningless bleating about a
core dump...)  We don't really want that sort of thing to happen unless
there's an internal failure in initdb, which this surely is not.

The best fix seems to be to move the collection of the password
earlier, so that it's done essentially as part of argument collection,
rather than at the rather ad-hoc time it was done before.

Back-patch to 9.6 where the problem was introduced.
src/bin/initdb/initdb.c