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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
