Re: Bug with pg_ctl -w/wait and config-only directories
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Magnus Hagander <magnus@hagander.net>, Peter Eisentraut <peter_e@gmx.net>, Fujii Masao <masao.fujii@gmail.com>, "Mr. Aaron W. Swenson" <titanofold@gentoo.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-10-04T01:50:17Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix nested PlaceHolderVar expressions that appear only in targetlists.
- ceaf5052c6a7 8.4.9 cited
Andrew Dunstan wrote: > > > On 10/03/2011 06:45 PM, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Excerpts from Bruce Momjian's message of lun oct 03 17:28:53 -0300 2011: > >>> Alvaro Herrera wrote: > >>>> Well, we have the Gentoo developer in this very thread. I'm sure they > >>>> would fix their command line if we gave them a pg_ctl that worked. > >>>> Surely the package that contains the init script also contains pg_ctl, > >>>> so they would both be upgraded simultaneously. > >>> What is the fix? If they started the server by using --data-directory, > >>> pg_ctl stop has no way to find the postmaster.pid file, and hence stop > >>> the server. Are you suggesting we remove this ability? > >> I am suggesting they don't start it by using --data-directory in the > >> first place. > > Agreed. If you remove that, the logical problem goes away and it > > becomes a simple problem of dumping the contents of postgresql.conf and > > having pg_ctl (and pg_upgrade) use that. Let me look at how much code > > that would take. > > > > Yeah, this pattern can be changed to have a config file that reads: > > data_directory = '/path/to/data' > include '/path/to/common/config' > > and I presume (or hope) that would meet your need, and not upset the FHS > purists. Actually, the existing setup is fine as long as there is something that tell us where to find the data directory. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +