On Tue, 17 Sep 2002, Tom Lane wrote:
> > I am waiting the result of the pg_dump from 7.2.x to 7.3 restore discussion.
>
> Right. We clearly have to support loading of 7.2 dumps; the only issue
> in my mind is exactly how we kluge that up ;-). I just talked to Bruce
> about this a little bit, an
OK, I have added this script to /contrib/adddepend with an appropriate
README. It seems to work quite well. It does require Pg:DBD. I will
add a mention of the script in the release notes.
---
Rod Taylor wrote:
> > Using
Oliver Elphick writes:
> We want PostgreSQL to be the best database. Why on earth can we not
> have the same ambition for the upgrade process?
We do have that ambition. We just don't have enough clues and time to
follow up on it.
--
Peter Eisentraut [EMAIL PROTECTED]
Christopher Kings-Lynne wrote:
> > Sounds good. I think the earliest we could be ready for beta2 is the
> > end of this week; sometime next week may be more realistic.
> >
> > Given that we'll be forcing an initdb for beta2 anyway, those who use
> > RPMs may be just as happy to have missed beta1.
> Sounds good. I think the earliest we could be ready for beta2 is the
> end of this week; sometime next week may be more realistic.
>
> Given that we'll be forcing an initdb for beta2 anyway, those who use
> RPMs may be just as happy to have missed beta1.
If an initdb is planned - did that spli
I am working on a README and will add this to /contrib. Thanks.
---
Rod Taylor wrote:
> > Using 7.3's pg_dump would help you with the GRANT issue, but AFAIR it
> > won't do anything for reconstructing serial or foreign-key
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Wednesday 18 September 2002 12:55 am, Tom Lane wrote:
>> But the system catalogs *store* that metadata.
> They _currently_ store the user's metadata. But that's my point -- does the
> user metadata that isn't typically substantially different after go
> Remember that Rod Taylor's written a script to fix at least the foreign key
> issue above. I think it'd be neat if that script were perfected and did
> serials as well and then we could recommend its use...
It does do serials (adds pg_depend entry -- which is just enough), as
well as changes u
On Wed, 2002-09-18 at 05:02, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > I'm unhappy because I know that I will get bug reports that I will have
> > to deal with. They will take time and effort and would not be necessary
> > if we had a seamless upgrade path.
>
> This last line gave me a ch
On Wednesday 18 September 2002 12:55 am, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Not talking about a freeze. Talking about separation of system/feature
> > metadata from user metadata that wouldn't change in the upgrade anyway --
> But the system catalogs *store* that metada
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Tuesday 17 September 2002 11:51 pm, Tom Lane wrote:
>> The bald fact of the matter is that we are still a good ways away from
>> the point where we might be willing to freeze the system catalogs.
> Not talking about a freeze. Talking about separation
On Tuesday 17 September 2002 11:51 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> >> How does pg_upgrade work?
> > [ pretty good description ]
> You missed a key point, which is that pg_upgrade does not even try to
> cope with version-to-version system catalog changes. It assumes
On Tuesday 17 September 2002 11:22 pm, Bruce Momjian wrote:
> This is a better description tha[n] I could make. If you look at the
> script it is very well commented so you should be able to see it works.
> Also, read the manual page first.
I don't know how, but this time looking at the script, I
Oliver Elphick wrote:
> On Tue, 2002-09-17 at 21:40, Tom Lane wrote:
> > In short, I'm not sure why you and Oliver are so unhappy. We may not
> > have made the world better than before for upgrade scenarios, but I
> > don't think we've made it worse either.
>
> I'm unhappy because I know that I
On Wed, 2002-09-18 at 04:22, Bruce Momjian wrote:
>
> In summary, doing any kind of data changes is quite involved (smaller
> tuple header for 7.3) and because it has to be redone for every release,
> it is quite a pain.
Is it feasible to make a utility to rewrite each table, shortening the
hea
Lamar Owen <[EMAIL PROTECTED]> writes:
>> How does pg_upgrade work?
> [ pretty good description ]
You missed a key point, which is that pg_upgrade does not even try to
cope with version-to-version system catalog changes. It assumes it can
use pg_dump to dump and reload the database schema. So t
On Tue, 2002-09-17 at 21:40, Tom Lane wrote:
> In short, I'm not sure why you and Oliver are so unhappy. We may not
> have made the world better than before for upgrade scenarios, but I
> don't think we've made it worse either.
I'm unhappy because I know that I will get bug reports that I will h
>
> I'd give up a few extensibility features for solid upgrading. If
> I didn't
> have so much invested in PostgreSQL I might take a hard look at MySQL 4,
> since data migration has heretofore been one of their few real
> strengths.
> But I've got three years of RPM maintenance and five years of
This is a better description that I could make. If you look at the
script it is very well commented so you should be able to see it works.
Also, read the manual page first.
In summary, doing any kind of data changes is quite involved (smaller
tuple header for 7.3) and because it has to be redo
On Tuesday 17 September 2002 10:27 pm, Christopher Kings-Lynne wrote:
> Lamar Owen wrote:
> > Sorry, it's just a sore spot for me, this whole
> > upgrade issue.
> IS there any solution to Postgres's upgrade problems? I mean, ever? With
> the complex catalog design, etc - how is it every possibl
> > How does pg_upgrade work?
>
> pg_upgrade sort of worked for 7.2 but I got to it too late and I didn't
> properly expand the pg_clog files. In 7.3, the file format has changed.
> If we don't change the format for 7.4, I can do it, but I have to add
> schema stuff to it. Shouldn't be too hard
Christopher Kings-Lynne wrote:
> > I just want people to not get bit in a bad way and decide they
> > don't want to
> > use PostgreSQL after all. And with the new features of 7.3, lots
> > of users
> > who might have begun with 7.2 are going to want to upgrade -- but
> > if it's too
> > painful..
> I just want people to not get bit in a bad way and decide they
> don't want to
> use PostgreSQL after all. And with the new features of 7.3, lots
> of users
> who might have begun with 7.2 are going to want to upgrade -- but
> if it's too
> painful Sorry, it's just a sore spot for me, this
On Tuesday 17 September 2002 04:40 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... What I am looking
> > at is whether the user will have to run 7.3's pg_dump in order to migrate
> > older data.
> AFAIK this is not *necessary*, though it may be *helpful*. Aside from
> the OP
> * A reloaded dump will not create dependencies between serial columns
> and sequence objects, nor between triggers and foreign key
> constraints, thus 7.3's nifty new support for DROP CONSTRAINT won't
> work, nor will dropping a table make its associated sequences go away.
> However, thi
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... What I am looking
> > at is whether the user will have to run 7.3's pg_dump in order to migrate
> > older data.
>
> AFAIK this is not *necessary*, though it may be *helpful*. Aside from
> the OPAQUE issue, which we will fix one w
> Using 7.3's pg_dump would help you with the GRANT issue, but AFAIR it
> won't do anything for reconstructing serial or foreign-key dependencies.
The below perl script can help with both of those.
http://www.rbt.ca/postgresql/upgrade/upgrade.tar.gz
Explanation URL:
http://www.rbt.ca/postgresql
Lamar Owen <[EMAIL PROTECTED]> writes:
> ... What I am looking
> at is whether the user will have to run 7.3's pg_dump in order to migrate
> older data.
AFAIK this is not *necessary*, though it may be *helpful*. Aside from
the OPAQUE issue, which we will fix one way or another, I am aware of
t
On Tuesday 17 September 2002 03:59 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > as yet. I would expect to be able to release an RPMset for beta 2 if
> > that is a week or two off.
> Given that we'll be forcing an initdb for beta2 anyway, those who use
> RPMs may be just as ha
Lamar Owen <[EMAIL PROTECTED]> writes:
> I have a basic build running, but it's not releasable. I haven't had time to
> go through it with the properly fine-toothed comb that I want to as yet. I
> would expect to be able to release an RPMset for beta 2 if that is a week or
> two off.
Sounds g
Having not seen anyone asking about the progress on the 7.3beta RPMset, I
thought I would give a statement as to where things stand.
I am waiting the result of the pg_dump from 7.2.x to 7.3 restore discussion.
The structure of the entire packaging depends upon knowing how the upgrade
will be
31 matches
Mail list logo
