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 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 pip
On Tue, 2012-08-14 at 17:56 -0400, Tom Lane wrote:
> Peter Eisentraut 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?
>
On Tue, Aug 14, 2012 at 06:53:49PM -0400, Tom Lane wrote:
> Bruce Momjian 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
> >
Bruce Momjian 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 communica
On Tue, Aug 14, 2012 at 05:56:39PM -0400, Tom Lane wrote:
> Peter Eisentraut 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
> >> subpro
Peter Eisentraut 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 server on
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
pg_upg
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
>> 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 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
http://www.postgresql.org/docs/9.2/static/pgup
On Thu, Aug 9, 2012 at 09:20:23AM -0400, Robert Haas wrote:
> On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian 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'
On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian 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 these chang
On Wed, Aug 8, 2012 at 06:42:27PM -0400, Tom Lane wrote:
> Alvaro Herrera 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.or
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 wrote:
> > > > Yes, the list of rough edg
Alvaro Herrera 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 currently req
On Wed, Aug 8, 2012 at 4:29 PM, Alvaro Herrera 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 a file, then
>
i l
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 wrote:
> > > Yes, the list of rough edges is the 14-steps you have to perform to run
> > > pg_upgrade, as docum
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
> On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian 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/do
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian 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 reduce the numbe
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 wrote:
> > > >> I don't disagree with pg_u
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 wrote:
> > >> I don't disagree with pg_upgrade being operationally complex, but I
> > >> don't see how this rela
On Tue, Aug 7, 2012 at 03:06:23PM +0200, Magnus Hagander wrote:
> On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian 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 wrote:
> >> >> I don't disagree with pg_upgrade being operat
On Fri, Aug 3, 2012 at 10:02 PM, Bruce Momjian 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 wrote:
>> >> I don't disagree with pg_upgrade being operationally complex, but I
>> >> don't see how this relates to contrib vs. no
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
> On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian 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
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian 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.
>
> Well, per
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
> u
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?
> >
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 i
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 Thu, Jul 7, 2011 at 06:09:54PM -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut 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
> >>
On tor, 2011-07-07 at 18:09 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut 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
> >> [-Wfor
I wrote:
> Peter Eisentraut 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 not, w
Peter Eisentraut 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 compiler opti
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 con
34 matches
Mail list logo
