On Wednesday 10 July 2002 04:42 pm, Jan Wieck wrote:
> Lamar Owen wrote:
> > On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> > > The problem why this conflicts with these package managers is,
> > > because they work package per package, instead of looking at the
> > > big picture. Who said
Lamar Owen wrote:
> On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
>
> > The problem why this conflicts with these package managers is,
> > because they work package per package, instead of looking at the
> > big picture. Who said you can replace package A before running
> > the pre-upgrad
On Wednesday 10 July 2002 10:26 am, Hannu Krosing wrote:
> Actually, if the python dumper can be made to work somewhat reiably it
> can be run after install/upgrade without too much trouble.
Yes, yes, of course. My bad -- brain needs oil change... :-)
Thanks for the links to the python stuff, p
On Wed, 2002-07-10 at 19:56, Lamar Owen wrote:
> On Wednesday 10 July 2002 11:48 am, Hannu Krosing wrote:
> > On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> > > On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > > > And I have written custom postgres table dumpers in python without too
On Wednesday 10 July 2002 11:48 am, Hannu Krosing wrote:
> On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> > On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > > And I have written custom postgres table dumpers in python without too
> > > much effort (except reverse-engineering the page
On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
>
> > The only problem with this approach is that it needs maintaining
> > separately from postgres proper. OTOH, this may also be a good thing, as
> > a separate reimplementation is only kno
On Wed, 2002-07-10 at 16:15, Lamar Owen wrote:
> [cc: trimmed]
>
> On Wednesday 10 July 2002 03:42 am, Jan Wieck wrote:
> >How many rewrite rules have to be converted into
> > the new parsetree format during an RPM upgrade?
>
> Don't know if anything comparable exists.
>
IMHO the best solution
On Wed, 2002-07-10 at 16:20, Lamar Owen wrote:
> On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> > On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> > > The wc utility isn't in the path in an OS install situation. The df
> > > utility isn't in the path, either. You can use python, thou
On Wednesday 10 July 2002 09:11 am, Hannu Krosing wrote:
> On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> > The wc utility isn't in the path in an OS install situation. The df
> > utility isn't in the path, either. You can use python, though. :-) Not
> > that that would be a good thing in thi
[cc: trimmed]
On Wednesday 10 July 2002 03:42 am, Jan Wieck wrote:
> Lamar Owen wrote:
> > As a note of interest, RPM itself is backed by a database, db3. Prior to
> > version 4.x, it was backed by db1. Upgrading between the versions of RPM
> > is simply -- installing db3 and dependenies, upgra
On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> Oliver Elphick wrote:
> > The current upgrade process for PostgreSQL is founded on the idea that
> > people build from source. With binary distributions, half the users
> > wouldn't know what to do with source; they expect (and are entitled t
On Wed, 2002-07-10 at 01:09, Lamar Owen wrote:
> On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> > > The pre-upgrade script is run in an environment that isn't robust enough
> > > to handle that. What if you run out of disk space during
Lamar Owen wrote:
>
> [replying to myself]
> On Tuesday 09 July 2002 07:34 pm, Lamar Owen wrote:
> > if you do this. Already RPM can rollback the transaction being done on the
> > RPM database (it's a db3 database system), but rolling back the filesystem
> > is a little different.
>
> As a note
Oliver Elphick wrote:
>
> The current upgrade process for PostgreSQL is founded on the idea that
> people build from source. With binary distributions, half the users
> wouldn't know what to do with source; they expect (and are entitled to
> expect) that an upgrade will progress without the need
On Wed, 2002-07-10 at 00:09, Lamar Owen wrote:
> On Tuesday 09 July 2002 04:17 pm, Hannu Krosing
> > It is quite easy to both check for a running postmaster and start/stop
> > one.
>
> Not when there is no ps in your path. Or pg_ctl for that matter. Nor is
> there necessarily a /proc tree wai
> Can the ports system take into account the space required for a dumpfile?? :-)
It cheats by keeping a backup of the old version -- makes an installable
package out of the currently installed version. This is removed once
the package has been successfully upgraded (including dependencies).
On
[replying to myself]
On Tuesday 09 July 2002 07:34 pm, Lamar Owen wrote:
> if you do this. Already RPM can rollback the transaction being done on the
> RPM database (it's a db3 database system), but rolling back the filesystem
> is a little different.
As a note of interest, RPM itself is backed
On Tuesday 09 July 2002 07:19 pm, Rod Taylor wrote:
> On Tue, 2002-07-09 at 19:09, Lamar Owen wrote:
> > And what if you have enough disk space to do the dump, but then that
> > causes the OS upgrade to abort because there wasn't enough space left to
> > finish upgrading (larger packages, perhaps)
On Tuesday 09 July 2002 06:20 pm, Peter Eisentraut wrote:
> The problem in an extensible system such as PostgreSQL is that virtually
> every feature change is reflected by a change in the structure of the
> system catalogs. It wouldn't be such a terribly big problem in theory to
> make the backen
On Tue, 2002-07-09 at 19:09, Lamar Owen wrote:
> On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> > > The pre-upgrade script is run in an environment that isn't robust enough
> > > to handle that. What if you run out of disk space during
On Tuesday 09 July 2002 04:17 pm, Hannu Krosing wrote:
> On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> > The pre-upgrade script is run in an environment that isn't robust enough
> > to handle that. What if you run out of disk space during the dump?
> You can either check beforehand or abort a
On Tue, 2002-07-09 at 22:10, Lamar Owen wrote:
> On Tuesday 09 July 2002 01:46 pm, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> > > The main problem is getting access to the user data after an upgrade.
>
> > Can't it be dumped in pre-upgrade script ?
>
> The pre-
Oliver Elphick writes:
> I never have understood why the basic table structure changes so much
> that it can't be read; just what is involved in getting the ability to
> read old versions?
The problem in an extensible system such as PostgreSQL is that virtually
every feature change is reflected
On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > > Oh, that is a problem. We would have to require the old executables.
> >
> > Could this be solved with packaging? Meaning can postmasters from old versions
> > be packed with a new
On Tuesday 09 July 2002 01:46 pm, Hannu Krosing wrote:
> On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> > The main problem is getting access to the user data after an upgrade.
> Can't it be dumped in pre-upgrade script ?
The pre-upgrade script is run in an environment that isn't robust eno
On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote:
> > The big change was from 6.x to 7.x where a chunk of data moved from end
> > of page to start of page and tableoid column was added. Otherways the
> > table structure is quite simple. The diff
On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote:
> The big change was from 6.x to 7.x where a chunk of data moved from end
> of page to start of page and tableoid column was added. Otherways the
> table structure is quite simple. The difficulties with user _data_ can
> be mainly because of binary
On Tue, 2002-07-09 at 17:49, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote:
> > On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote:
> > > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > > > Example: When PG 7.3 is released, the RPM / deb / setup.exe include th
On Tue, 2002-07-09 at 16:41, Hannu Krosing wrote:
> On Tue, 2002-07-09 at 13:48, Oliver Elphick wrote:
> > On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > > Example: When PG 7.3 is released, the RPM / deb / setup.exe include the
> > > postmaster binary for v 7.2 (perhaps two or three
On Tuesday 09 July 2002 11:41 am, Hannu Krosing wrote:
> The old postmaster should not be built/distributed. As it is for
> _upgrading_ only, you just have to _keep_ it when doing an upgrade, not
> build a new "old" one ;)
Let me reiterate one thing about this. In the midst of a total OS upgrade
On Tue, 2002-07-09 at 17:19, Lamar Owen wrote:
> On Monday 08 July 2002 03:20 pm, Jan Wieck wrote:
> > Another good example: let's add a field to some parsenode struct (was
> > there a release where this didn't happen?). This causes the NodeOut()
> > results to become a little different, which act
On Monday 08 July 2002 03:20 pm, Jan Wieck wrote:
> Zeugswetter Andreas SB SD wrote:
> > Unless it dumps binary representation of columns, a standalone dumper
> > would still need to load all the output function shared libs for custom
> > types (or not support custom types which would imho not be
On Tue, 2002-07-09 at 01:30, Matthew T. O'Connor wrote:
> > Oh, that is a problem. We would have to require the old executables.
>
> Could this be solved with packaging? Meaning can postmasters from old versions
> be packed with a new release strictly for the purpose of upgrading? It is my
>
> > Keys to this working:
> > 1.) Must not require the old version executable backend. There are a
number
> > of reasons why this might be, but the biggest is due to the way much
> > upgrading works in practice -- the old executables are typically gone by
the
> > time the new package is inst
On Tue, 2002-07-09 at 00:20, Jan Wieck wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > No, what I envisioned was a standalone dumper that can produce dump output
> > > without having a backend at all. If this dumper knows about the various
> > > binary formats, and knows how to get my data i
Zeugswetter Andreas SB SD wrote:
>
> > No, what I envisioned was a standalone dumper that can produce dump output
> > without having a backend at all. If this dumper knows about the various
> > binary formats, and knows how to get my data into a form I can then restore
> > reliably, I will be sa
> No, what I envisioned was a standalone dumper that can produce dump output
> without having a backend at all. If this dumper knows about the various
> binary formats, and knows how to get my data into a form I can then restore
> reliably, I will be satisfied. If it can be easily automated
Lamar Owen <[EMAIL PROTECTED]> writes:
>> What it *does* do is effectively mask a DBA error.
> This is a satisfactory answer. In the context of the RPM distribution, if the
> initscript is used the DBA error probability is greatly reduced, thus the
> initscript can safely initdb.
Fair enough
On Sat, 6 Jul 2002, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote:
> >> One other usability note: why can't postmaster perform the steps of
> >> an initdb if -D points to an empty directory?
>
> > Rank newbies shouldn'
On Saturday 06 July 2002 11:15 am, Tom Lane wrote:
> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> > On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote:
> >> One other usability note: why can't postmaster perform the steps of
> >> an initdb if -D points to an empty directory?
> > Rank new
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote:
>> One other usability note: why can't postmaster perform the steps of
>> an initdb if -D points to an empty directory?
> Rank newbies shouldn't be protected in this way, partly because if
>
On generic recovery...
What is wrong with this strategy...
0. Put the database in single user mode.
1. Dump the Schema, with creation order properly defined, and with all
constraints written to a separate file. (IOW, one file contains the
bare tables with no index, constraint or trigger stuff,
On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote:
> One other usability note: why can't postmaster perform the steps of
> an initdb if -D points to an empty directory? It's not that much
> code, is it? (I know that one extra step isn't backbreaking, but
> I'm looking at this from a ra
On Fri, 2002-07-05 at 17:39, Lamar Owen wrote:
> No, what I envisioned was a standalone dumper that can produce dump output
> without having a backend at all. If this dumper knows about the various
> binary formats, and knows how to get my data into a form I can then restore
> reliably, I will
Lamar Owen wrote:
> On Wednesday 03 July 2002 12:09 pm, Bruce Momjian wrote:
> > Hannu Krosing wrote:
> > > AFAIK I can run as many backends as I like (up to some practical limit)
> > > on the same comuter at the same time, as long as they use different
> > > ports and different data directories.
On Wednesday 03 July 2002 12:09 pm, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > AFAIK I can run as many backends as I like (up to some practical limit)
> > on the same comuter at the same time, as long as they use different
> > ports and different data directories.
> We don't have an automate
Hannu Krosing wrote:
> >
> > However, the limiting factor is that we don't have a mechanism to have
> > both databases running at the same time currently.
>
> How so ?
>
> AFAIK I can run as many backends as I like (up to some practical limit)
> on the same comuter at the same time, as long as
On Wed, 2002-07-03 at 17:28, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > > Our very extensibility is our weakness for upgrades. Can it be worked around?
> > > Anyone have any ideas?
> >
> > Perhaps we can keep an old postgres binary + old backend around and then
> > use it in single-user m
Hannu Krosing wrote:
> > Our very extensibility is our weakness for upgrades. Can it be worked around?
> > Anyone have any ideas?
>
> Perhaps we can keep an old postgres binary + old backend around and then
> use it in single-user mode to do a pg_dump into our running backend.
That brings up
Lamar Owen wrote:
> On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> > Lamar Owen wrote:
> > > [...]
> > > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > > deal of promise for seamless binary 'in place' upgrading. He has been
> > > able to write code to read multi
On Tue, 2002-07-02 at 21:50, Lamar Owen wrote:
> On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> > Lamar Owen wrote:
> > > [...]
> > > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > > deal of promise for seamless binary 'in place' upgrading. He has been
> > > abl
Le Jeudi 27 Juin 2002 05:48, Christopher Kings-Lynne a écrit :
> I am willing to supply a complete, friendly, powerful and pretty installer
> program, based on NSIS.
Maybe you should contact Dave Page, who wrote pgAdmin2 and the ODBC
installers. Maybe you can both work on the installer.
By the
On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> Lamar Owen wrote:
> > [...]
> > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > deal of promise for seamless binary 'in place' upgrading. He has been
> > able to write code to read multiple versions' database structu
Lamar Owen wrote:
> [...]
>
> And if having a working, usable, Win32 native port gets the subject of good
> upgrading higher up the priority list, BY ALL MEANS LET'S SUPPORT WIN32
> NATIVELY! :-) (and I despise Win32)
Hehehe :-)
> [...]
> Martin O has come up with a 'pg_fsck' utility that,
On Tuesday 02 July 2002 09:52 am, Jan Wieck wrote:
> Christopher Kings-Lynne wrote:
> > > > It would all work out of the box and would do wonderful things for
> > > > the Postgres community.
> > > I like this idea, but let me just bring one little issue to note: are
> > > you going to handle upgr
> The question is not how to replace some .EXE and .DLL files or modify
> something in the registry. The question is what to do with the existing
> databases in the case of a catalog version change. You have to dump and
> restore.
pg_upgrade?
Otherwise: no upgrades persay, but you can intall th
Christopher Kings-Lynne wrote:
>
> > > It would all work out of the box and would do wonderful things for the
> > > Postgres community.
> >
> > I like this idea, but let me just bring one little issue to note: are you
> > going to handle upgrades, and if so, how? How are you going to
> > do a ma
gt;;
"HACKERS" <[EMAIL PROTECTED]>
Sent: Tuesday, July 02, 2002 12:48 PM
Subject: Re: [HACKERS] (A) native Windows port
> > > It would all work out of the box and would do wonderful things for the
> > > Postgres community.
> >
> > I like this idea, b
> > It would all work out of the box and would do wonderful things for the
> > Postgres community.
>
> I like this idea, but let me just bring one little issue to note: are you
> going to handle upgrades, and if so, how? How are you going to
> do a major
> version upgrade?
Well, the easiest way
On Wednesday 26 June 2002 11:48 pm, Christopher Kings-Lynne wrote:
> I suggest that pgAdmin is included in the install process. Imagine it - a
> win32 person downloads a single .exe, with contents bzip2'd. They run the
> installer, it asks them to agree to license, shows splash screen, asks them
> As for project coordination, I am willing to setup and maintain a page
> similar to the (horribly outdated) ones that I did for Toast and RI.
> Summarizing project status, pointing to resources, instructions, maybe a
> roadmap, TODO, you name it.
I am willing to supply a complete, friendly, pow
Jan Wieck wrote:
> As for project coordination, I am willing to setup and maintain a page
> similar to the (horribly outdated) ones that I did for Toast and RI.
> Summarizing project status, pointing to resources, instructions, maybe a
> roadmap, TODO, you name it.
Great. Please see roadmap in T
> -Original Message-
> From: Jan Wieck [mailto:[EMAIL PROTECTED]]
> Sent: 26 June 2002 15:45
> To: HACKERS
> Subject: [HACKERS] (A) native Windows port
>
>
> As for project coordination, I am willing to setup and
> maintain a page similar to the (horrib
Hackers,
as some of you figured already, Katie Ward and I are working fulltime on
PostgreSQL and are actually doing a native Win32 port. This port is not
based on CygWIN, Apache or any other compatibility library but uses 100%
native Windows functionality only.
We already have it far enough to
64 matches
Mail list logo
