On 2015-12-12 17:31:49 -0500, Tom Lane wrote:
> I thought this sounded like a nice lazy-Saturday project, so I started
> poking at it, and attached is a WIP patch.
Not bad, not bad at all.
> After some experimentation, I came up with the idea of executing any
> time that a semicolon followed by two newlines is seen. ...
> but it turns out that no such case exists anywhere in initdb's data.
Not pretty, but hardly any worse than the current situation.
> I'm not particularly wedded to this rule. In principle we could go so
> far as to import psql's code that parses commands and figures out which
> semicolons are command terminators --- but that is a pretty large chunk
> of code, and I think it'd really be overkill considering that initdb
> deals only with fixed input scripts.
Having that code somewhere abstracted wouldn't be bad though, extension
scripts have a somewhat similar problem.
> Anyway, the attached patch tweaks postgres.c to follow that rule instead
> of slurp-to-EOF when -j is given. I doubt that being non-backwards-
> compatible is a problem here; in fact, I'm tempted to rip out the -j
> switch altogether and just have standalone mode always parse input the
> same way.
No objection here.
> Does anyone know of people using standalone mode other than
> for initdb?
Unfortunately yes. There's docker instances around that configure users
and everything using it.
> The other part of the patch modifies initdb to do all its post-bootstrap
> steps using a single standalone backend session. I had to remove the
> code that currently prints out progress markers for individual phases
> of that processing, so that now you get output that looks like
That's cool too. Besides processing the .bki files, and there largely
reg*_in, the many restarts are the most expensive parts of initdb.
Greetings,
Andres Freund