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

Re: [GENERAL] 'pg_ctl -w' times out when unix_socket_directory is

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] 'pg_ctl -w' times out when unix_socket_directory is
Date: 2006-09-28 16:20:10
Message-ID: 1159460410.7578.231.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Thu, 2006-09-28 at 10:05 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > I have attached a patch. I wrote it very quickly, but it seems to work
> > as I expect.
> I don't think this is very workable as a postgresql.conf parser ...
> at minimum it needs to handle quoted strings correctly, and really it
> ought to deal with file inclusions.
> There are other reasons why pg_ctl needs to look at
> postgresql.conf --- it currently fails to cope with
> config-file-outside-the-datadir cases, and that can't be fixed except by
> extracting the data_directory setting from the config file.  What we
> probably need to do is port guc-file.l into the pg_ctl environment.
> (Not sure if it's feasible to use a single source file for both cases,
> though that would be nice if not too messy.)

And same for reading the port out of postgresql.conf, right?

I was a little skeptical that the function would always work. However,
to the extent that it looked for the correct port, it makes sense it
should look at the correct unix_socket_directory also. I think my patch
handles the simplest cases correctly (a simple single-quoted string),
and I don't think it breaks anything.

I can understand that we want a more correct solution to search for both

I could make an attempt to port guc-file.l. However, if you were
planning on fixing this for 8.2, I can't make any guarantees. It does
seem like a bug to me, especially since the FreeBSD port of postgres
uses pg_ctl -w in the startup script (and probably a lot of other

	Jeff Davis

In response to

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2006-09-28 16:22:23
Subject: Re: Another idea for dealing with cmin/cmax
Previous:From: Stefan KaltenbrunnerDate: 2006-09-28 16:16:09
Subject: Re: -HEAD planner issue wrt hash_joins on dbt3 ?

pgsql-general by date

Next:From: Kai HessingDate: 2006-09-28 16:30:09
Subject: Re: Dead Lock problem with 8.1.3
Previous:From: Guy RouillierDate: 2006-09-28 16:19:38
Subject: Re: How to create nightly backups in Linux

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