Re: [HACKERS] Upgrading rant.

2003-01-07 Thread Manfred Koizar
On Fri, 03 Jan 2003 15:37:56 -0500, Tom Lane [EMAIL PROTECTED] wrote: The system tables are not the problem. [...] Changes in the on-disk representation of user tables would be harder to deal with, but they are also much rarer (AFAIR we've only done that twice: WAL required additions to page and

Re: [HACKERS] Upgrading rant.

2003-01-07 Thread Manfred Koizar
On Tue, 07 Jan 2003 11:18:15 +0100, I wrote: what I have hacked together yesterday afternoon: [included it twice] Sorry! Servus Manfred ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail

Re: [HACKERS] Upgrading rant.

2003-01-06 Thread Thomas O'Connell
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Bruce Momjian) wrote: Is pg_upgrade too hard to run? Is no one really interested in it? As an end-user, I'm very interested in pg_upgrade, but I think it's kind of a chicken and egg problem. Without much of a guarantee that it's fail-safe,

Re: [HACKERS] Upgrading rant.

2003-01-06 Thread Thomas O'Connell
Exactly. I've got something that works and is, in fact, the recommended method for upgrading, currently. For me to switch, I'd need something in which the developers were confident enough to recommend. And even to test, I'd need something more than what is available right now. -tfo In

Re: [HACKERS] Upgrading rant.

2003-01-06 Thread Bruce Momjian
I think you are on to something here. Clearly dump/reload works, and testing pg_upgrade is time-consuming, so people aren't as inclined to jump into testing. It isn't quite like testing a bugfix or new feature. --- Thomas

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Greg Copeland
On Sat, 2003-01-04 at 22:37, Tom Lane wrote: You're missing the point: I don't want to lock out everyone but the super-user, I want to lock out everyone, period. Superusers are just as likely to screw up pg_upgrade as anyone else. BTW: $ postmaster -N 1 -c

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread mlw
Bruce Momjian wrote: pg_upgrade does work, assuming there are no changes to the index or heap file formats. (However, I now need to update it for schemas.) However, the last time I worked on it for 7.2, no one was really interested in testing it, so it never got done. In fact, there was a

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Dave Page
-Original Message- From: mlw [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 16:36 To: Bruce Momjian Cc: Tom Lane; Hannu Krosing; Lamar Owen; [EMAIL PROTECTED] Subject: Re: [HACKERS] Upgrading rant. (2) Upgrade HAS HAS HAS to be fool proof. Agreed. No one is going to use

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Bruce Momjian
mlw wrote: I have the USA tiger census data in a database, it is over 60G with indexes, 30G+ of just data. Do you know how long that will take to dump and restore? Making one index on some of the tables takes 20 minutes. Oh, come on. How many tigers are their in the USA? Certainly not 30G+

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Bruce Momjian
Greg Copeland wrote: On Sat, 2003-01-04 at 22:37, Tom Lane wrote: You're missing the point: I don't want to lock out everyone but the super-user, I want to lock out everyone, period. Superusers are just as likely to screw up pg_upgrade as anyone else. BTW: $ postmaster -N 1 -c

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, taking up the pg_upgrade banner, I think there are two things missing from the current code: 1) schema awareness -- easily fixed with some code 2) need to creat clog files to match incremented xid I can do 1, and I think

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: VACUUM FREEZE. Interesting idea. Did we have that in 7.2? I never thought of using it. Good idea. IIRC, it was new in 7.2 --- but pg_upgrade goes back further than that. I am not sure if this idea just escaped us before, or if there's a hole in it.

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: ... On top of that, that's also the risk of someone being a superuser. They will ALWAYS have the power to hose things. Period. As such, I don't consider that to be a valid argument. That was my feeling too. If you can't trust the other admins, it

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Lamar Owen
On Saturday 04 January 2003 21:12, Peter Eisentraut wrote: I would recommend requiring users to do the schema dump before upgrading the binaries, so they'd do Nice theory. Won't work in RPM practice. I can't require the user to do _anything_. Due to the rules of RPM's, I can't even ask the

Re: [HACKERS] Upgrading rant.

2003-01-05 Thread Lamar Owen
On Sunday 05 January 2003 23:10, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: It is very possible that the supporting libc shared libraries will be removed by the OS upgrade -- the old binaries may not even run when it is critical that they do run. Urgh, that's a mess. Yah, it is

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Tom Lane
Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it. I tackled this issue

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Greg Copeland
On Sat, 2003-01-04 at 09:53, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Peter Eisentraut
Tom Lane writes: This would require a nontrivial amount of work (notably, we'd have to be able to get pg_dump to run against a standalone backend) but I don't think I'd trust pg_upgrade as a production-grade tool until its invocation method looks like the above. I would recommend requiring

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: This would require a nontrivial amount of work (notably, we'd have to be able to get pg_dump to run against a standalone backend) but I don't think I'd trust pg_upgrade as a production-grade tool until its invocation method looks

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Bruce Momjian
Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it.

Re: [HACKERS] Upgrading rant.

2003-01-04 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: That's a good kluge, but still a kluge: it doesn't completely guarantee that no one else connects while pg_upgrade is trying to do its thing. I was thinking about using GUC: #max_connections = 32

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread mlw
Tom Lane wrote: Well, this is exactly the issue: someone would have to put substantial amounts of time into update mechanisms and/or maintenance of obsolete versions, as opposed to features, performance improvements, or bug fixes. Personally, I feel that if we weren't working as hard as we

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Hannu Krosing
On Fri, 2003-01-03 at 13:45, mlw wrote: Tom Lane wrote: Personally, I feel that if we weren't working as hard as we could on features/performance/bugfixes, the upgrade issue would be moot because there wouldn't *be* any reason to upgrade. What about the standard Microsoft reason for

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Lamar Owen
On Thursday 02 January 2003 19:26, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. It was very bad. It simply would not build -- I guess it's the gcc 3 stuff. If you don't know *exactly* why it doesn't build, I

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread mlw
Hannu Krosing wrote: I don't think the main issues are with file _formats_ but rather with system file structures - AFAIK it is a fundamental design decision (arguably a design flaw ;( ) that we use system tables straight from page cache via C structure pointers, even though there seems to be

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes: I don't think the main issues are with file _formats_ but rather with system file structures - AFAIK it is a fundamental design decision (arguably a design flaw ;( ) that we use system tables straight from page cache via C structure pointers, The system

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Lamar Owen
On Friday 03 January 2003 15:16, Lamar Owen wrote: On Thursday 02 January 2003 19:26, Tom Lane wrote: Lamar Owen Wrote THIS DOESN'T HAPPEN WITH MySQL. Oh? Do they have a crystal ball that lets them predict incompatible future platform changes? No, they just allow for the old format,

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Bruce Momjian
Tom Lane wrote: The system tables are not the problem. pg_upgrade has shown how we can have cross-version upgrades no matter how much the system catalogs change (a good thing too, because we cannot freeze the system catalog layout without bringing development to a standstill). A schema-only

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Serguei Mokhov
- Original Message - From: Bruce Momjian [EMAIL PROTECTED] Sent: January 03, 2003 6:31 PM Tom Lane wrote: The system tables are not the problem. pg_upgrade has shown how we can have cross-version upgrades no matter how much the system catalogs change (a good thing too, because we

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Bruce Momjian
Serguei Mokhov wrote: pg_upgrade does work, assuming there are no changes to the index or heap file formats. (However, I now need to update it for schemas.) However, the last time I worked on it for 7.2, no one was really interested in testing it, so it never got done. In fact, there

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: There isn't any fundamental reason why we cannot have a pg_upgrade utility; claiming that there is something wrong with how we handle catalog changes misses the point. pg_upgrade does work, assuming there are no changes to the index or heap file

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Bruce Momjian
OK, taking up the pg_upgrade banner, I think there are two things missing from the current code: 1) schema awareness -- easily fixed with some code 2) need to creat clog files to match incremented xid I can do 1, and I think Tom can help me with 2. Then folks can test it and see how it works.

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: There isn't any fundamental reason why we cannot have a pg_upgrade utility; claiming that there is something wrong with how we handle catalog changes misses the point. pg_upgrade does work, assuming there are no changes to the

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Lamar Owen
On Friday 03 January 2003 18:31, Bruce Momjian wrote: Tom Lane wrote: There isn't any fundamental reason why we cannot have a pg_upgrade utility; claiming that there is something wrong with how we handle catalog changes misses the point. The point is that *someone would have to do the

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: OK, taking up the pg_upgrade banner, I think there are two things missing from the current code: 1) schema awareness -- easily fixed with some code 2) need to creat clog files to match incremented xid I can do 1, and I think Tom can help me with 2.

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Is pg_upgrade too hard to run? It is hard and dangerous to run (IMHO). One thing I would like to see that would make it much safer to run is to recast it to operate through standalone backends. That is, the idea is bring down old postmaster

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Oliver Elphick
On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it. I tackled this issue in the Debian upgrade scripts. I close the

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Dan Langille
On Fri, 3 Jan 2003, Bruce Momjian wrote: Is pg_upgrade too hard to run? Is no one really interested in it? All of my boxes are still on 7.2.3. Does that represent a viable test base? ---(end of broadcast)--- TIP 6: Have you searched our list

Re: [HACKERS] Upgrading rant.

2003-01-03 Thread Christopher Kings-Lynne
pg_upgrade does work, assuming there are no changes to the index or heap file formats. (However, I now need to update it for schemas.) However, the last time I worked on it for 7.2, no one was really interested in testing it, so it never got done. In fact, there was a bug in the handling

Re: [HACKERS] Upgrading rant.

2003-01-02 Thread Ross J. Reedstrom
On Thu, Jan 02, 2003 at 07:26:06PM -0500, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's fault we can't do a sane upgrade. I think you're wasting your time trying to hold us to a higher standard of

Re: [HACKERS] Upgrading rant.

2003-01-02 Thread Tom Lane
Lamar Owen [EMAIL PROTECTED] writes: So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. It was very bad. It simply would not build -- I guess it's the gcc 3 stuff. If you don't know *exactly* why it doesn't build, I don't think you should be blaming us for it. (FWIW, I