State of Beta 2

[Dennis Gearon]

Re: State of Beta 2

Andrew Rawnsley wrote:
[color=blue]
>
> eRserver should be able to migrate the data. If you make heavy use of
> sequences, schemas and other such things it won't help you for those.
>
> <snip>[/color]
[color=blue]
> Using eRserver may help you work around the problem, given certain
> conditions. It doesn't solve it. I think if we can get Mr. Drake's
> initiative off the ground we may at least figure out if there is a
> solution.[/color]


So a replication application
IS
a method to migrate
OR CAN BE MADE
to do it somewhat
AND is a RELATED
project to the migration tool.

Again, I wonder what on the TODO's or any other roadmap is related and
should be part of a comprehensive plan to drain the swamp and not just
club alligators over the head?


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Joshua D. Drake]

Re: State of Beta 2

[color=blue]
> If bugfixes were consistently backported, and support was provided for
> older versions running on newer OS's, then this wouldn't be as much of
> a problem. But we orphan our code afte one version cycle; 7.0.x is
> completely unsupported, for instance, while even 7.2.x is virtually
> unsupported. My hat's off to Red Hat for backporting the buffer
> overflow fixes to all their supported versions; we certainly wouldn't
> have don it. And 7.3.x will be unsupported once we get past 7.4
> release, right? So in order to get critical bug fixes, users must
> upgrade to a later codebase, and go through the pain of upgrading
> their data.[/color]


Command Prompt is supporting the 7.3 series until 2005 and that includes
backporting certain features and bug fixes. The reality is that most
(with the exception of the Linux kernel and maybe Apache) open source
projects don't support back releases. That is the point of commercial
releases such as RedHat DB and Mammoth. We will support the the older
releases for some time.

If you want to have continued support for an older rev, purchase a
commercial version. I am not trying to push my product here, but frankly
I think your argument is weak. There is zero reason for the community to
support previous version of code. Maybe until 7.4 reaches 7.4.1 or
something but longer? Why? The community should be focusing on
generating new, better, faster, cleaner code.

That is just my .02.

Joshua Drake



[color=blue]
>[color=green]
>> K, looking back through that it almost sounds like a ramble ...
>> hopefully
>> you understand what I'm asking ...[/color]
>
>
> *I* should complain about a ramble? :-)[/color]


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Re: State of Beta 2

"Joshua D. Drake" <jd@commandprom pt.com> writes:[color=blue]
> If you want to have continued support for an older rev, purchase a
> commercial version. I am not trying to push my product here, but frankly
> I think your argument is weak. There is zero reason for the community to
> support previous version of code. Maybe until 7.4 reaches 7.4.1 or
> something but longer? Why? The community should be focusing on
> generating new, better, faster, cleaner code.[/color]

I tend to agree on this point. Red Hat is also in the business of
supporting back-releases of PG, and I believe PG Inc, SRA, and others
will happily do it too. I don't think it's the development community's
job to do that.

[ This does not, however, really bear on the primary issue, which is how
can we make upgrading less unpleasant for people with large databases.
We do need to address that somehow. ]

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Andrew Sullivan]

Re: need for in-place upgrades (was Re: State of Beta 2)

On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
[color=blue]
> So instead of 1TB of 15K fiber channel disks (and the requisite
> controllers, shelves, RAID overhead, etc), we'd need *two* TB of
> 15K fiber channel disks (and the requisite controllers, shelves,
> RAID overhead, etc) just for the 1 time per year when we'd upgrade
> PostgreSQL?[/color]

Nope. You also need it for the time when your vendor sells
controllers or chips or whatever with known flaws, and you end up
having hardware that falls over 8 or 9 times in a row.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@liberty rms.info> M2P 2A8
+1 416 646 3304 x110


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Andrew Sullivan]

Re: need for in-place upgrades (was Re: State of Beta 2)

On Sat, Sep 13, 2003 at 07:16:28PM -0400, Lamar Owen wrote:[color=blue]
>
> Can eRserver replicate a 7.3.x to a 7.2.x? Or 7.4.x to 7.3.x?[/color]

Yes. Well, 7.3 to 7.2, anyway: we just tested it (my colleague,
Tariq Muhammad did it).

A

----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@liberty rms.info> M2P 2A8
+1 416 646 3304 x110


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Andrew Sullivan]

Re: need for in-place upgrades (was Re: State of Beta 2)

On Sat, Sep 13, 2003 at 10:27:59PM -0300, Marc G. Fournier wrote:[color=blue]
>
> I thought we were talking about upgrades here?[/color]

You do upgrades without being able to roll back?

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@liberty rms.info> M2P 2A8
+1 416 646 3304 x110


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Andrew Sullivan]

Re: State of Beta 2

On Thu, Sep 18, 2003 at 12:11:18PM -0400, Lamar Owen wrote:[color=blue]
> RTA. It's been hashed, rehashed, and hashed again. I've asked twice if
> eRserver can replicate a 7.3 database onto a 7.4 server (or a 7.2 onto a
> 7.3); that question has yet to be answered. If it can do this, then I[/color]

Sorry, I've been swamped, and not reading mail as much as I'd like.
But I just answered this for 7.2/7.3.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@liberty rms.info> M2P 2A8
+1 416 646 3304 x110


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Marc G. Fournier]

Re: need for in-place upgrades (was Re: State of Beta 2)



On Thu, 18 Sep 2003, Andrew Sullivan wrote:
[color=blue]
> On Sat, Sep 13, 2003 at 10:27:59PM -0300, Marc G. Fournier wrote:[color=green]
> >
> > I thought we were talking about upgrades here?[/color]
>
> You do upgrades without being able to roll back?[/color]

Hadn't thought of it that way ... but, what would prompt someone to
upgrade, then use something like erserver to roll back? All I can think
of is that the upgrade caused alot of problems with the application
itself, but in a case like that, would you have the time to be able to
're-replicate' back to the old version?



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Christopher Browne]

Re: need for in-place upgrades

scrappy@postgre sql.org ("Marc G. Fournier") writes:[color=blue]
> On Thu, 18 Sep 2003, Andrew Sullivan wrote:
>[color=green]
>> On Sat, Sep 13, 2003 at 10:27:59PM -0300, Marc G. Fournier wrote:[color=darkred]
>> >
>> > I thought we were talking about upgrades here?[/color]
>>
>> You do upgrades without being able to roll back?[/color]
>
> Hadn't thought of it that way ... but, what would prompt someone to
> upgrade, then use something like erserver to roll back? All I can
> think of is that the upgrade caused alot of problems with the
> application itself, but in a case like that, would you have the time
> to be able to 're-replicate' back to the old version?[/color]

Suppose we have two dbs:

db_a - Old version
db_b - New version

Start by replicating db_a to db_b.

The approach would presumably be that at the time of the upgrade, you
shut off the applications hitting db_a (injecting changes into the
source), and let the final set of changes flow thru to db_b.

That brings db_a and db_b to having the same set of data.

Then reverse the flow, so that db_b becomes master, flowing changes to
db_a. Restart the applications, configuring them to hit db_b.

db_a should then be just a little bit behind db_b, and be a "recovery
plan" in case the new version played out badly.

That's surely not what you'd _expect_; the point of the exercise was
for the upgrade to be an improvement. But if something Truly Evil
happened, you might have to. And when people are talking about "risk
management," and ask what you do if Evil Occurs, this is the way the
answer works.

It ought to be pretty cheap, performance-wise, to do things this way,
certainly not _more_ expensive than the replication was to keep db_b
up to date.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc") )

http://www.ntlug.org/~cbbrowne/oses.html

Rules of the Evil Overlord #149. "Ropes supporting various fixtures
will not be tied next to open windows or staircases, and chandeliers
will be hung way at the top of the ceiling."
<http://www.eviloverlor d.com/>

[Ron Johnson]

Re: need for in-place upgrades (was Re: State of Beta 2)

On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:[color=blue]
> On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
>[color=green]
> > So instead of 1TB of 15K fiber channel disks (and the requisite
> > controllers, shelves, RAID overhead, etc), we'd need *two* TB of
> > 15K fiber channel disks (and the requisite controllers, shelves,
> > RAID overhead, etc) just for the 1 time per year when we'd upgrade
> > PostgreSQL?[/color]
>
> Nope. You also need it for the time when your vendor sells
> controllers or chips or whatever with known flaws, and you end up
> having hardware that falls over 8 or 9 times in a row.[/color]

????

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@c ox.net
Jefferson, LA USA

"A C program is like a fast dance on a newly waxed dance floor
by people carrying razors."
Waldi Ravens


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Christopher Browne]

Re: need for in-place upgrades

Centuries ago, Nostradamus foresaw when ron.l.johnson@c ox.net (Ron Johnson) would write:[color=blue]
> On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:[color=green]
>> On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
>>[color=darkred]
>> > So instead of 1TB of 15K fiber channel disks (and the requisite
>> > controllers, shelves, RAID overhead, etc), we'd need *two* TB of
>> > 15K fiber channel disks (and the requisite controllers, shelves,
>> > RAID overhead, etc) just for the 1 time per year when we'd upgrade
>> > PostgreSQL?[/color]
>>
>> Nope. You also need it for the time when your vendor sells
>> controllers or chips or whatever with known flaws, and you end up
>> having hardware that falls over 8 or 9 times in a row.[/color]
>
> ????[/color]

This of course never happens in real life; expensive hardware is
_always_ UTTERLY reliable.

And the hardware vendors all have the same high standards as, well,
certain database vendors we might think of.

After all, Oracle and MySQL AB would surely never mislead their
customers about the merits of their database products any more than
HP, Sun, or IBM would about the possibility of their hardware having
tiny flaws.

And I would never mislead anyone, either. I'm sure I got a full 8
hours sleep last night. I'm sure of it...
--
"cbbrowne","@", "cbbrowne.c om"

http://www3.sympatico.ca/cbbrowne/finances.html

"XML combines all the inefficiency of text-based formats with most of the
unreadability of binary formats :-) " -- Oren Tirosh

[Christopher Browne]

Re: need for in-place upgrades

Centuries ago, Nostradamus foresaw when ron.l.johnson@c ox.net (Ron Johnson) would write:[color=blue]
> On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:[color=green]
>> On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
>>[color=darkred]
>> > So instead of 1TB of 15K fiber channel disks (and the requisite
>> > controllers, shelves, RAID overhead, etc), we'd need *two* TB of
>> > 15K fiber channel disks (and the requisite controllers, shelves,
>> > RAID overhead, etc) just for the 1 time per year when we'd upgrade
>> > PostgreSQL?[/color]
>>
>> Nope. You also need it for the time when your vendor sells
>> controllers or chips or whatever with known flaws, and you end up
>> having hardware that falls over 8 or 9 times in a row.[/color]
>
> ????[/color]

This of course never happens in real life; expensive hardware is
_always_ UTTERLY reliable.

And the hardware vendors all have the same high standards as, well,
certain database vendors we might think of.

After all, Oracle and MySQL AB would surely never mislead their
customers about the merits of their database products any more than
HP, Sun, or IBM would about the possibility of their hardware having
tiny flaws.

And I would never mislead anyone, either. I'm sure I got a full 8
hours sleep last night. I'm sure of it...
--
"cbbrowne","@", "cbbrowne.c om"

http://www3.sympatico.ca/cbbrowne/finances.html

"XML combines all the inefficiency of text-based formats with most of the
unreadability of binary formats :-) " -- Oren Tirosh

[Christopher Browne]

Re: need for in-place upgrades

ron.l.johnson@c ox.net (Ron Johnson) wrote:[color=blue]
> On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:[color=green]
>> On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
>>[color=darkred]
>> > So instead of 1TB of 15K fiber channel disks (and the requisite
>> > controllers, shelves, RAID overhead, etc), we'd need *two* TB of
>> > 15K fiber channel disks (and the requisite controllers, shelves,
>> > RAID overhead, etc) just for the 1 time per year when we'd upgrade
>> > PostgreSQL?[/color]
>>
>> Nope. You also need it for the time when your vendor sells
>> controllers or chips or whatever with known flaws, and you end up
>> having hardware that falls over 8 or 9 times in a row.[/color]
>
> ????[/color]

This of course never happens in real life; expensive hardware is
_always_ UTTERLY reliable.

And the hardware vendors all have the same high standards as, well,
certain database vendors we might think of.

After all, Oracle and MySQL AB would surely never mislead their
customers about the merits of their database products any more than
HP, Sun, or IBM would about the possibility of their hardware having
tiny flaws.

And I would /never/ claim to have lost sleep as a result of flakey
hardware. Particularly not when it's a HA fibrechannel array. I'm
/sure/ that has never happened to anyone. [The irony herre should be
causing people to say "ow!"]
--
"cbbrowne","@", "cbbrowne.c om"

http://www3.sympatico.ca/cbbrowne/finances.html

"XML combines all the inefficiency of text-based formats with most of the
unreadability of binary formats :-) " -- Oren Tirosh

[Christopher Browne]

Re: need for in-place upgrades

ron.l.johnson@c ox.net (Ron Johnson) wrote:[color=blue]
> On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:[color=green]
>> On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
>>[color=darkred]
>> > So instead of 1TB of 15K fiber channel disks (and the requisite
>> > controllers, shelves, RAID overhead, etc), we'd need *two* TB of
>> > 15K fiber channel disks (and the requisite controllers, shelves,
>> > RAID overhead, etc) just for the 1 time per year when we'd upgrade
>> > PostgreSQL?[/color]
>>
>> Nope. You also need it for the time when your vendor sells
>> controllers or chips or whatever with known flaws, and you end up
>> having hardware that falls over 8 or 9 times in a row.[/color]
>
> ????[/color]

This of course never happens in real life; expensive hardware is
_always_ UTTERLY reliable.

And the hardware vendors all have the same high standards as, well,
certain database vendors we might think of.

After all, Oracle and MySQL AB would surely never mislead their
customers about the merits of their database products any more than
HP, Sun, or IBM would about the possibility of their hardware having
tiny flaws.

And I would /never/ claim to have lost sleep as a result of flakey
hardware. Particularly not when it's a HA fibrechannel array. I'm
/sure/ that has never happened to anyone. [The irony herre should be
causing people to say "ow!"]
--
"cbbrowne","@", "cbbrowne.c om"

http://www3.sympatico.ca/cbbrowne/finances.html

"XML combines all the inefficiency of text-based formats with most of the
unreadability of binary formats :-) " -- Oren Tirosh

[Marc G. Fournier]

Re: State of Beta 2



On Thu, 18 Sep 2003, Lamar Owen wrote:
[color=blue]
> Marc G. Fournier wrote:[color=green]
> > 'K, I had already answered it as part of this thread when I suggested
> > doing exactly that ... in response to which several ppl questioned the
> > feasibility of setting up a duplicate system with >1TB of disk space to do
> > the replication over to ...[/color]
>
> The quote mentioned is a question, not an answer. You said:[color=green]
> > 'k, but is it out of the question to pick up a duplicate server, and use
> > something like eRServer to replicate the databases between the two
> > systems, with the new system having the upgraded database version running
> > on it, and then cutting over once its all in sync?[/color]
>
> 'Something like eRserver' doesn't give me enough detail; so I asked if
> eRserver could do this, mentioning specific version numbers. A straight
> answer -- yes it can, or no it can't -- would be nice. So you're saying
> that eRserver can do this, right? Now if there just wasn't that java
> dependency.... Although the contrib rserv might suffice for data
> migration capabilities.[/color]

Sorry, but I hadn't actually seen your question about it ... but, yes,
erserver can do this ... as far as I know, going from, say, v7.2 -> v7.4
shouldn't be an issue either, but I only know of a few doing v7.2->v7.3
migrations with it so far ...


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster