Re: BUG #3969: pg_ctl cannot detect server startup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: BUG #3969: pg_ctl cannot detect server startup
Date: 2008-02-20 18:14:52
Message-ID: 13566.1203531292@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-patches

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> I found this bug comes from the definition of WHITESPACE
> characters in pg_ctl.c. WHITESPACE is defined as folows:
> #define WHITESPACE "\f\n\r\t\v"
> In fact, WHITESPACE does not contain whilespace (0x20) :-(

Ooops :-(

> I attach a patch to fix it.

Actually, this coding seems gratuitously ugly/inconsistent/fragile, so
I'm inclined to rewrite it to eliminate WHITESPACE altogether. It seems
bad style to switch between loops using isspace() and an entirely
different type of string searching that (as demonstrated by the bug)
isn't easy to keep in sync. Adding an additional loop of the same kind
to scan over the parameter value would take a couple more lines, but
I think it'll be a lot more readable.

In fact there are more bugs here: it won't deal correctly with a
quoted port value, and it'd be fooled by '-p' appearing in the argument
value for another option type. I'm not sure how tense we should be
about getting it to exactly match the backend's behavior for corner
cases, but at the very least it probably shouldn't be fooled by -p
appearing inside quotes.

> BTW, I also found similar definitions in some places.
> (Please grep with "\t\n\r".)
> They are a bit different from each other.
> For example, whitespaces is defined as " \t\n\r" in tzparser.c.
> Is it ok in the inconsistency? Or, should we always use " \f\n\r\t\v" ?

Not sure. One point is that vertical whitespace shouldn't necessarily
be treated the same as horizontal whitespace.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alex Hunsaker 2008-02-20 21:03:29 BUG #3973: pg_dump using inherited tables do not always restore
Previous Message Tom Lane 2008-02-20 16:15:19 Re: GetNewOidWithIndex can cause infinite loop on user tables(not catalog).

Browse pgsql-patches by date

  From Date Subject
Next Message Alex Hunsaker 2008-02-20 21:03:29 BUG #3973: pg_dump using inherited tables do not always restore
Previous Message Heikki Linnakangas 2008-02-20 10:29:26 Re: tzcode update