Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > "Joshua D. Drake" writes:
> > > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > > >> I think it will be confusing if we change the name, so I vote to not
> > > >> change the name.
> > >
> > > > Actually, I would vot
2010/5/6 Tom Lane :
> Bruce Momjian writes:
>> OK, seems people like pg_upgrade, but do we call it "pgupgrade" or
>> "pg_upgrade"?
>
pg_upgrade sounds good. I just bet that some users will want it to
upgrade their postgresql from 9.0.0 to 9.0.1..
> The latter. The former is unreadable.
>
>
On Thu, May 6, 2010 at 8:10 PM, Thom Brown wrote:
> You will call it pg_upgrade. I have spoken.
> Thom
LOL.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Bruce Momjian writes:
> OK, seems people like pg_upgrade, but do we call it "pgupgrade" or
> "pg_upgrade"?
The latter. The former is unreadable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 6 May 2010 20:55, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > "Joshua D. Drake" writes:
> > > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > > >> I think it will be confusing if we change the name, so I vote to not
> > > >> change the name.
> > >
> > > >
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" writes:
> > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > >> I think it will be confusing if we change the name, so I vote to not
> > >> change the name.
> >
> > > Actually, I would vote yes to change the name.
> >
> > I
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
> >> It seems copying over pg_statistic would require preservation of
> >> pg_class.oid. Right now we only preserve pg_class.relfilenode.
>
> > That could be fixed easily by crea
Alvaro Herrera writes:
> Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
>> It seems copying over pg_statistic would require preservation of
>> pg_class.oid. Right now we only preserve pg_class.relfilenode.
> That could be fixed easily by creating a throwaway table which
Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
> It seems copying over pg_statistic would require preservation of
> pg_class.oid. Right now we only preserve pg_class.relfilenode.
That could be fixed easily by creating a throwaway table which included the
qualified table
Tom Lane wrote:
> Bruce Momjian writes:
> > Jesper Krogh wrote:
> >> I should have written:
> >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
> >> itself?
>
> > Yeah, the statistics are part of the system tables, and system tables
> > are fully handled by pg_dumpall -
Tom Lane wrote:
> Bruce Momjian writes:
> > Jesper Krogh wrote:
> >> I should have written:
> >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
> >> itself?
>
> > Yeah, the statistics are part of the system tables, and system tables
> > are fully handled by pg_dumpall -
Bruce Momjian writes:
> Jesper Krogh wrote:
>> I should have written:
>> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
>> itself?
> Yeah, the statistics are part of the system tables, and system tables
> are fully handled by pg_dumpall --schema-only (except for statist
Bruce Momjian wrote:
> > The database (of a reasonable size) is useless until statistics is
> > available.
> >
> > I guess it is because pg_dump/restore doesn't do it either.
>
> Yeah, the statistics are part of the system tables, and system tables
> are fully handled by pg_dumpall --schema-only
Jesper Krogh wrote:
> On 2010-05-06 06:41, Alvaro Herrera wrote:
> > Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
> >
> >
> >> Q: I read you pdf, why isn't statistics copied over? It seems to be the
> >> last
> >> part missing from doing an upgrade in a few minutes.
Jesper Krogh writes:
> I did go the painful way (dump+restore) at that point in time.
> It was an 8.1 - 8.3 migration. Since then data has grown and the dump
> restore is even less favorable on the 8.3 -> 9.0 migration.
>
> So in general the pg_migrator way seems to be the only way to aviod
> the
On 2010-05-06 06:41, Alvaro Herrera wrote:
Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
Q: I read you pdf, why isn't statistics copied over? It seems to be the last
part missing from doing an upgrade in a few minutes.
Seems fraught with peril, and a bit poi
Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
> Q: I read you pdf, why isn't statistics copied over? It seems to be the last
> part missing from doing an upgrade in a few minutes.
Seems fraught with peril, and a bit pointless. What's so bad about having to
run ANALYZE a
On 2010-05-06 01:45, Bruce Momjian wrote:
Jesper Krogh wrote:
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
wrote:
Now you tell me how awful this idea really is :)
I'm not sure I can
Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> >> I think it will be confusing if we change the name, so I vote to not
> >> change the name.
>
> > Actually, I would vote yes to change the name.
>
> I lean that way too. If there were no hi
"Joshua D. Drake" writes:
> On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
>> I think it will be confusing if we change the name, so I vote to not
>> change the name.
> Actually, I would vote yes to change the name.
I lean that way too. If there were no history involved, we'd certainly
p
On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >>
> >> So what was the conclusion here? Is pg_migrator going to be in contrib
> >> for beta2 or 3, after cleaning it up?
> >
> > Thanks for asking. :-) I can
On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>>
>> So what was the conclusion here? Is pg_migrator going to be in contrib
>> for beta2 or 3, after cleaning it up?
>
> Thanks for asking. :-) I can add pg_migrator to contrib by the end of
> next week, so it will be
Jesper Krogh wrote:
> On 2010-05-03 23:09, Bruce Momjian wrote:
> > Robert Haas wrote:
> >
> >> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> >> wrote:
> >>
> >>> Now you tell me how awful this idea really is :)
> >>>
> >> I'm not sure I can count that high. :-)
> >>
Alvaro Herrera wrote:
>
> So what was the conclusion here? Is pg_migrator going to be in contrib
> for beta2 or 3, after cleaning it up?
Thanks for asking. :-) I can add pg_migrator to contrib by the end of
next week, so it will be in beta2. I will remove 8.4 as a migration
target, which will
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine wrote:
Now you tell me how awful this idea really is :)
I'm not sure I can count that high. :-)
While I can't improve on Robert's reply, I can supply a PDF a
So what was the conclusion here? Is pg_migrator going to be in contrib
for beta2 or 3, after cleaning it up?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Greg Smith wrote:
> Bruce Momjian wrote:
> > As a summary, let me list the migrations pg_migrator supports:
> > 8.3 -> 8.4
> > 8.4 -> 9.0
> > 8.3 -> 9.0
> > Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
> > doesn't have access to the features we added in Postg
Robert Haas wrote:
> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> wrote:
> > Now you tell me how awful this idea really is :)
>
> I'm not sure I can count that high. :-)
While I can't improve on Robert's reply, I can supply a PDF about how
pg_migrator works:
http://momjian.us/ma
Bruce Momjian wrote:
As a summary, let me list the migrations pg_migrator supports:
8.3 -> 8.4
8.4 -> 9.0
8.3 -> 9.0
Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
doesn't have access to the features we added in Postgres 9.0.
Tom is right that the
On Mon, 2010-05-03 at 16:12 -0400, Robert Haas wrote:
> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> wrote:
> > Now you tell me how awful this idea really is :)
>
> I'm not sure I can count that high. :-)
You don't have to...
NaN
Joshua D. Drake
>
> ...Robert
>
--
PostgreSQL.org
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine wrote:
> Now you tell me how awful this idea really is :)
I'm not sure I can count that high. :-)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
Andrew Dunstan writes:
> We need to be thinking more now about such a contingency. Postgres use in
> very large installations is now at such a level that requiring a
> pg_dump/pg_restore is really not an option for many users. If pg_migrator is
> not always going to work then we need to be addre
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > For example, I assume there
> > will be some major version of Postgres where pg_migrator will not work
> > at all.
> >
> >
>
> We need to be thinking more now about such a contingency. Postgres use
> in very large installations is now at s
Bruce Momjian wrote:
For example, I assume there
will be some major version of Postgres where pg_migrator will not work
at all.
We need to be thinking more now about such a contingency. Postgres use
in very large installations is now at such a level that requiring a
pg_dump/pg_restore i
Bruce Momjian wrote:
> Well, that is going to make the documentation more complicated than it
> already is. Why mention a process in 9.0 that no one needs to use? I
> am not writing the docs for some hypothetical release, but for 9.0.
> When we have some restriction, we can document that.
>
> M
Peter Eisentraut wrote:
> On l?r, 2010-05-01 at 17:26 -0400, Bruce Momjian wrote:
> > I am unclear why it would be in /bin if it requires 15 steps to run
> > and is run only once by only some users. It seems natural
> > for /contrib, like pgcrypto.
>
> Well, pg_resetxlog is also rarely run by mos
Tom Lane wrote:
> Robert Haas writes:
> > Yeah. It's not uncommon to want to upgrade by more than one release at
> > a time, and I haven't heard any reason why we should arbitrarily
> > refuse to support that. Of course we may need to do that eventually
> > for some specific reason, but it seems l
Robert Haas writes:
> Yeah. It's not uncommon to want to upgrade by more than one release at
> a time, and I haven't heard any reason why we should arbitrarily
> refuse to support that. Of course we may need to do that eventually
> for some specific reason, but it seems like we should only conside
Robert Haas wrote:
> > My guess is that when that happens we would just document/enforce it
> > in
> > pg_migrator, but I don't see why we would arbitrarily restrict
> > pg_migrator at this time.
>
> Yeah. It's not uncommon to want to upgrade by more than one release at
> a time, and I haven't hea
On May 2, 2010, at 12:01 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> Andrew Dunstan wrote:
I thought the idea was just to support migration from version N to
version N+1.
>>
>>> Oh, I will also support many older _source_ versions, like 8.3 and
>>> 8.4.
>>
>>
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >> I thought the idea was just to support migration from version N to
> >> version N+1.
>
> > Oh, I will also support many older _source_ versions, like 8.3 and 8.4.
>
> Really? Nobody else has bought into that, and it's not
Tom Lane wrote:
> Andrew Dunstan writes:
> > Robert Haas wrote:
> >> I don't think it's going
> >> to be practical to retain all the migration code for every pair of
> >> versions forever,
>
> > I thought the idea was just to support migration from version N to
> > version N+1.
>
> Yeah. I th
Robert Haas wrote:
> On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan wrote:
> > Robert Haas wrote:
> >>
> >> ?I don't think it's going
> >> to be practical to retain all the migration code for every pair of
> >> versions forever,
> >
> > I thought the idea was just to support migration from versio
Bruce Momjian writes:
> Andrew Dunstan wrote:
>> I thought the idea was just to support migration from version N to
>> version N+1.
> Oh, I will also support many older _source_ versions, like 8.3 and 8.4.
Really? Nobody else has bought into that, and it's not only pg_migrator
that would have
Andrew Dunstan wrote:
>
>
> Robert Haas wrote:
> > I don't think it's going
> > to be practical to retain all the migration code for every pair of
> > versions forever,
> >
>
> I thought the idea was just to support migration from version N to
> version N+1.
Oh, I will also support many o
Robert Haas wrote:
> On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian wrote:
> >> > Agreed, we're not holding up 9.0 for it. ?I think the main bit of work
> >> > that would be needed to put it into contrib would be to SGML-ize the
> >> > docs. ?Don't know if Bruce has got the time to get that done.
>
On lör, 2010-05-01 at 17:26 -0400, Bruce Momjian wrote:
> I am unclear why it would be in /bin if it requires 15 steps to run
> and is run only once by only some users. It seems natural
> for /contrib, like pgcrypto.
Well, pg_resetxlog is also rarely run by most users. It started in
contrib but
Robert Haas writes:
> On Sat, May 1, 2010 at 11:38 PM, Tom Lane wrote:
>> To the extent that future bug fixes are relevant to multiple versions
>> of pg_migrator, we could just apply them to multiple branches, same as
>> we manage such fixes for the core code. I don't see that trying to
>> have
On Sat, May 1, 2010 at 11:38 PM, Tom Lane wrote:
> To the extent that future bug fixes are relevant to multiple versions
> of pg_migrator, we could just apply them to multiple branches, same as
> we manage such fixes for the core code. I don't see that trying to
> have a single version of pg_migr
Andrew Dunstan writes:
> Robert Haas wrote:
>> I don't think it's going
>> to be practical to retain all the migration code for every pair of
>> versions forever,
> I thought the idea was just to support migration from version N to
> version N+1.
Yeah. I think trying to do more than that is j
On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>
>> I don't think it's going
>> to be practical to retain all the migration code for every pair of
>> versions forever,
>
> I thought the idea was just to support migration from version N to version
> N+1.
I think that
Robert Haas wrote:
I don't think it's going
to be practical to retain all the migration code for every pair of
versions forever,
I thought the idea was just to support migration from version N to
version N+1.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian wrote:
>> > Agreed, we're not holding up 9.0 for it. I think the main bit of work
>> > that would be needed to put it into contrib would be to SGML-ize the
>> > docs. Don't know if Bruce has got the time to get that done.
>>
>> Creating the SGML docs
C?dric Villemain wrote:
> 2010/5/1 Bruce Momjian :
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > While most of the limitations in previous versions of pg_migrator are
> >> > gone, there are still issues with migrating /contrib modules, and there
> >> > are many steps to its use.
> >>
> >>
2010/5/1 Bruce Momjian :
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > While most of the limitations in previous versions of pg_migrator are
>> > gone, there are still issues with migrating /contrib modules, and there
>> > are many steps to its use.
>>
>> > I think to attain mass usage of pg_mig
> > Agreed, we're not holding up 9.0 for it. I think the main bit of work
> > that would be needed to put it into contrib would be to SGML-ize the
> > docs. Don't know if Bruce has got the time to get that done.
>
> Creating the SGML docs is trivial, especially compared to the 9.0
> release note
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> >> I think that having it in contrib for a release cycle or so would be
> >> exactly the right approach, actually. ?Peter's position that it should
> >> be in /bin is fine *once the bugs are out*. ?Just d
Tom Lane wrote:
> Bruce Momjian writes:
> > While most of the limitations in previous versions of pg_migrator are
> > gone, there are still issues with migrating /contrib modules, and there
> > are many steps to its use.
>
> > I think to attain mass usage of pg_migrator, some type of one-click
Robert Haas writes:
> On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
>> I think that having it in contrib for a release cycle or so would be
>> exactly the right approach, actually. Peter's position that it should
>> be in /bin is fine *once the bugs are out*. Just dropping it there
>> doesn'
Bruce Momjian writes:
> While most of the limitations in previous versions of pg_migrator are
> gone, there are still issues with migrating /contrib modules, and there
> are many steps to its use.
> I think to attain mass usage of pg_migrator, some type of one-click
> installer has to be built
> I think the big question is whether we want to provide a binary upgrade
> facility for Postgres. If so, pg_migrator is the only facility
> currently available, and I can't imagine another option appearing. I
> would love for pg_migrator to be easier to use, but I can't figure out
> how that can
Robert Haas wrote:
> On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander
> >> wrote:
> >>> A lot of people are not willing to put stuff labeled "contrib" on
> >>> their production boxes.
> >>>
> >>> And as Tom says, even
On Sat, May 1, 2010 at 11:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
>>> A lot of people are not willing to put stuff labeled "contrib" on
>>> their production boxes.
>>>
>>> And as Tom says, even we *ourselves* acknowledge that things
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
> >> A lot of people are not willing to put stuff labeled "contrib" on
> >> their production boxes.
> >>
> >> And as Tom says, even we *ourselves* acknowledge that things in
> >> /contrib are held to
Robert Haas writes:
> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
>> A lot of people are not willing to put stuff labeled "contrib" on
>> their production boxes.
>>
>> And as Tom says, even we *ourselves* acknowledge that things in
>> /contrib are held to a lower standard. If we put t
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander wrote:
> On Sat, May 1, 2010 at 02:23, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> Dimitri Fontaine writes:
>>> > Peter Eisentraut writes:
>>> >> I also think that the standards for contrib should not be so lax that a
>>> >> completely new module
On Sat, May 1, 2010 at 02:23, Bruce Momjian wrote:
> Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Peter Eisentraut writes:
>> >> I also think that the standards for contrib should not be so lax that a
>> >> completely new module can be added after beta. (This is mostly informed
>> >> by the
Tom Lane wrote:
> Dimitri Fontaine writes:
> > Peter Eisentraut writes:
> >> I also think that the standards for contrib should not be so lax that a
> >> completely new module can be added after beta. (This is mostly informed
> >> by the feeling that contrib should go away entirely.)
>
> > +1
>
Andrew Dunstan writes:
> Quite so. Getting a better extensions mechanism doesn't mean we should
> abandon what we currently have, IMNSHO.
Yeah, agreed. Exactly what I proposed. The only change is the
distribution mean. Either we keep things as they are now exactly, or we
use the new Archive Netwo
On fre, 2010-04-30 at 10:45 -0400, Tom Lane wrote:
> In the end, the main useful function that contrib serves is to provide
> examples of how to write Postgres extensions.
Maybe, but pg_migrator surely doesn't fit that. And neither does about
a third of the other contrib modules, IMO.
> Because
Tom Lane wrote:
Dimitri Fontaine writes:
Peter Eisentraut writes:
I also think that the standards for contrib should not be so lax that a
completely new module can be added after beta. (This is mostly informed
by the feeling that contrib should go away entirely.)
+1
Dimitri Fontaine writes:
> Peter Eisentraut writes:
>> I also think that the standards for contrib should not be so lax that a
>> completely new module can be added after beta. (This is mostly informed
>> by the feeling that contrib should go away entirely.)
> +1
> For the record, the contrib
Peter Eisentraut writes:
> My personal feeling is that pg_migrator should be fully integrated, but
> it's too late for that, obviously. Let's do it for 9.1.
+1
> I also think that the standards for contrib should not be so lax that a
> completely new module can be added after beta. (This is mo
On tor, 2010-04-29 at 17:34 -0400, Bruce Momjian wrote:
> I talked to a few people personally about this, and it seems there was a
> misunderstanding. I was not asking if pg_migrator should be in 9.0
> beta1. I was asking if we should think about putting it into a later
> 9.0 beta, like 9.0 beta3
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> >
> > and most of the limitations of pg_migrator are gone when migrating to
> > 9.0, even from Postgres 8.3. This could help beta testers move their
> > data to 9.0 as well.
> >
> >
> Wouldn't this help even for beta1?
It would, but there is so muc
Mark Kirkwood writes:
> Bruce Momjian wrote:
>> and most of the limitations of pg_migrator are gone when migrating to
>> 9.0, even from Postgres 8.3. This could help beta testers move their
>> data to 9.0 as well.
> Wouldn't this help even for beta1?
It's too late for beta1. It probably should
Bruce Momjian wrote:
and most of the limitations of pg_migrator are gone when migrating to
9.0, even from Postgres 8.3. This could help beta testers move their
data to 9.0 as well.
Wouldn't this help even for beta1?
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> >> There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
> >> we still want to do that?
>
> > I think you articulated some pretty good reasons previously for
> > keeping it separa
78 matches
Mail list logo
