Re: Using a single standalone-backend run in initdb (was Re: Bootstrap DATA is a pita)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org, Caleb Welton <cwelton(at)pivotal(dot)io>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: Using a single standalone-backend run in initdb (was Re: Bootstrap DATA is a pita)
Date: 2015-12-17 16:19:28
Message-ID: 6322.1450369168@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> I use CREATE RULE within startup files in the fork that I maintain. I have
> lots of them, totaling perhaps 50k lines of rule code. I don't think any of that
> code would have a problem with the double-newline separation you propose,
> which seems a more elegant solution to me. Admittedly, the double-newline
> separation would need to be documented at the top of each sql file, otherwise
> it would be quite surprising to those unfamiliar with it.

> You mentioned upthread that introducing a syntax error in one of these files
> results in a not-so-helpful error message that dumps the contents of the
> entire file. I can confirm that happens, and is hardly useful.

Not having heard any ideas that sounded better than semi-newline-newline,
I went ahead and finished up this patch on that basis. Attached are two
patch files; the first one redefines the behavior of -j, and the second
one modifies initdb to use only one standalone-backend run. I present
them this way to emphasize that the -j change doesn't break much of
anything: initdb still works if you apply only the first patch. And
I didn't change anything in the initdb input files, except for adding
the comment documentation Mark suggests above.

In passing in the first patch, I got rid of the TCOP_DONTUSENEWLINE
#define, which could not have been used by anyone in a very long time
because it would break initdb. I then realized that
src/include/tcop/tcopdebug.h is completely dead code, because the
other debugging symbol it claims to specify got ripped out long ago.
And to add insult to injury, that file is included noplace. I imagine
Bruce's pgrminclude tool got rid of the inclusion that must once have
existed in postgres.c, after observing that postgres.c still compiled
without it :-(. (That tool really requires more adult supervision
than it has gotten.) So anyway, this patch removes tcopdebug.h entirely.

The second patch consists of removing extra backend starts/stops
and converting all of initdb's code to run in -j mode, rather than the
mishmash of -j and not-j behavior that was there before. I changed
all the semicolon-newlines in initdb's command strings to
semicolon-newline-newlines. As mentioned before, only a small number of
those changes *had* to be made to get it to work, namely the ones around
VACUUM and CREATE DATABASE statements, but I felt that for consistency
and error localization all of them should be changed. I also failed to
resist the temptation to const-ify some of the arrays more thoroughly.

Barring objections I'll push this into HEAD soon.

regards, tom lane

Attachment Content-Type Size
change-j-switch-behavior.patch text/x-diff 15.2 KB
initdb-with-fewer-backends.patch text/x-diff 33.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2015-12-17 17:04:25 Fwd: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Previous Message Aleksander Alekseev 2015-12-17 16:03:42 Re: Patch: fix lock contention for HASHHDR.mutex