On Tue, Aug 14, 2012 at 11:54:53PM -0400, Peter Eisentraut wrote:
On Tue, 2012-08-14 at 17:56 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
What about having single user mode talk fe/be protocol, and talk to it
via a UNIX
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
Another thing worth considering is to have pg_upgrade init, stop and
start clusters as necessary instead of requesting the user to do it.
I think this is two less steps.
Then you'd need to expose the entire pg_ctl shutdown mode logic through
Peter Eisentraut pete...@gmx.net writes:
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
What about having single user mode talk fe/be protocol, and talk to it via a
UNIX pipe, with pg_upgrade starting the single user backend as a subprocess?
I think that's essentially equivalent to starting the
On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
What about having single user mode talk fe/be protocol, and talk to it via
a UNIX pipe, with pg_upgrade starting the single user backend as a
Bruce Momjian br...@momjian.us writes:
On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
The implementation I'm visualizing is that a would-be client (think psql
or pg_dump, though the code would actually be in libpq) forks off a
process that becomes a standalone backend, and then they
On Tue, Aug 14, 2012 at 06:53:49PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
The implementation I'm visualizing is that a would-be client (think psql
or pg_dump, though the code would actually be in libpq) forks
On Tue, 2012-08-14 at 17:56 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 8/10/12 7:48 PM, Dimitri Fontaine wrote:
What about having single user mode talk fe/be protocol, and talk to it via
a UNIX pipe, with pg_upgrade starting the single user backend as a
On 8/8/12 5:29 PM, Alvaro Herrera wrote:
I think those 14 is a bit of a made-up number. Several of those steps
are about building pg_upgrade, not actually using it. And there are
some that are optional anyway.
Compare the pg_upgrade instructions
Another thing worth considering is to have pg_upgrade init, stop and
start clusters as necessary instead of requesting the user to do it.
I think this is two less steps.
Then you'd need to expose the entire pg_ctl shutdown mode logic through
pg_upgrade, which might not make things
On Sat, Aug 11, 2012 at 01:48:13AM +0200, Dimitri Fontaine wrote:
Another thing worth considering is to have pg_upgrade init, stop and
start clusters as necessary instead of requesting the user to do it.
I think this is two less steps.
Then you'd need to expose the entire pg_ctl
On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian br...@momjian.us wrote:
The point I think Robert was trying to make is that we need to cut down
not only the complexity of running pg_upgrade, but the number of failure
modes. At least that's how I'd define improvement here.
Agreed. Even with
On Thu, Aug 9, 2012 at 09:20:23AM -0400, Robert Haas wrote:
On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian br...@momjian.us wrote:
The point I think Robert was trying to make is that we need to cut down
not only the complexity of running pg_upgrade, but the number of failure
modes. At
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade, as documented in the pg_upgrade manual page:
http://www.postgresql.org/docs/9.2/static/pgupgrade.html
The unknown is how to
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade, as documented in the pg_upgrade manual page:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade,
On Wed, Aug 8, 2012 at 4:29 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I wonder if things would be facilitated by having a config file for
pg_upgrade to specify binary and PGDATA paths instead of having awkward
command line switches. That way you could request the user to create
such
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
I think this is one good idea:
http://archives.postgresql.org/message-id/29806.1340655...@sss.pgh.pa.us
If we
On Wed, Aug 8, 2012 at 05:29:49PM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of
On Wed, Aug 8, 2012 at 06:42:27PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
I think this is one good idea:
On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian br...@momjian.us wrote:
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree with pg_upgrade being operationally complex, but I
don't see how this
On Tue, Aug 7, 2012 at 03:06:23PM +0200, Magnus Hagander wrote:
On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian br...@momjian.us wrote:
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree with
Excerpts from Bruce Momjian's message of vie ago 03 16:02:28 -0400 2012:
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree with pg_upgrade being operationally complex, but I
don't see how
On Tue, Aug 7, 2012 at 10:38:52AM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie ago 03 16:02:28 -0400 2012:
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree
On Thu, Jul 7, 2011 at 06:09:54PM -0400, Tom Lane wrote:
I wrote:
Peter Eisentraut pete...@gmx.net writes:
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
Excerpts from Bruce Momjian's message of vie ago 03 12:44:35 -0400 2012:
I changed a prep_status() call to pg_log() as you suggested, and
backpatched to 9.2. Patch attached.
I dunno about this particular patch, but if we ever want to move
pg_upgrade out of contrib we will have to stare hard
On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie ago 03 12:44:35 -0400 2012:
I changed a prep_status() call to pg_log() as you suggested, and
backpatched to 9.2. Patch attached.
I dunno about this particular patch, but if we
On Fri, Aug 3, 2012 at 03:10:24PM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie ago 03 13:32:21 -0400 2012:
On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
How ready are we to move it to src/bin/? Is it sensible to do so in
9.3?
We have
Excerpts from Bruce Momjian's message of vie ago 03 13:32:21 -0400 2012:
On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
How ready are we to move it to src/bin/? Is it sensible to do so in
9.3?
We have talked about that. Several people felt the instructions for
using
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree with pg_upgrade being operationally complex, but I
don't see how this relates to contrib vs. non-contrib at all. Are we
supposed to only have simple programs in src/bin? That seems a
strange policy.
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian br...@momjian.us wrote:
I don't disagree with pg_upgrade being operationally complex, but I
don't see how this relates to contrib vs. non-contrib at all. Are we
supposed to only have
On tor, 2011-07-07 at 18:09 -0400, Tom Lane wrote:
I wrote:
Peter Eisentraut pete...@gmx.net writes:
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
So the options I can see are either adding the compiler option
-Wno-format-zero-length (with
Peter Eisentraut pete...@gmx.net writes:
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
So the options I can see are either adding the
I wrote:
Peter Eisentraut pete...@gmx.net writes:
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
Shouldn't it be prep_status(\n)? If
34 matches
Mail list logo
