Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-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

pgsql-bugs by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group