Re: Bug with pg_ctl -w/wait and config-only directories
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, "Mr. Aaron W. Swenson" <titanofold@gentoo.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-10-03T19:09:47Z
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
Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of lun oct 03 16:03:47 -0300 2011: > > > > I'm not sure how big the overlap is - would it be easier if you moved > > > the required functionality into pg_upgrade itself, as you mentioned at > > > some point? As in, would it be easier to fix the config-only directory > > > case for the limited subset of functionality that pg_upgrade needs? > > > > Not really --- it is the -w/wait mode pg_upgrade needs. There is a lot > > of new code in pg_ctl that reads the postmaster.pid file for socket > > location, port number, etc, that doesn't make sense to duplicate. > > Frankly, there is the huge problem that they might specify the data > > directory on the command line --- that would be a bear to support. > > How about creating a library with the controlling stuff that's shared by > pg_ctl and pg_upgrade? Fine, but again, unlikely to be backpatched, which means +2 years. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +