Anyone out there using beta 2 in production situations? Comments on
stability? I am rolling out a project in the next 4 weeks, and really
don't want to go though an upgrade soon after its released on an
Unsuspecting Client, so I would LIKE to start working with 7.4.
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
Nov 11 '05
236  9423 
Joshua D. Drake wrote: It is alot but is is not a lot for something like an Insurance company
or a bank. Also 100TB is probably non-compressed although 30TB is still
large.
Our requirements are such that this figure is our best guess after
compression. The amount of data prior to compression is much larger,
and consists of highly compressible astronomical observations in FITS
format.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Joshua D. Drake wrote: Sure but IMHO it would be more important to fix bugs like the parser not
correctly using indexes on bigint unless the value is quoted...
I think everyone would agree that not having to use initdb would be nice
but I think there is much more important things to focus on.
Important is relative.
Besides if you are upgrading PostgreSQL in a production environment I
would assume there would be an extremely valid reason. If the reason is
big enough to do a major version upgrade then an initdb shouldn't be all
that bad of a requirement.
I'm not going to rehash the arguments I have made before; they are all
archived. Suffice to say you are simply wrong. The number of
complaints over the years shows that there IS a need.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
When I started this thread I made comment on the fact that this initdb
issue was treated somewhat "casually" on the lists. Not trying to
flame, or be an ass or anything, but this is kind of what I meant.
Yes, I know there many important issues the developers (bless their
overworked fingers) want/need to address that affect many people, and
I'm not going to presume to fault their choices. Some things make more
difference to others (the bigint indexing issue means little to me, for
example), so we try to point out these things in the hope that someone
may pick up on it, or the discussion may bear fruitful solutions that
no one had considered.
The initdb situation is a significant problem/obstacle to many people.
Avoiding it would be far more than 'nice' for us.
On Monday, September 15, 2003, at 02:24 PM, Joshua D. Drake wrote: Strawmen. If we provide a good upgrade capability, we would just
simply have to think about upgrades before changing features like
that. The upgrade code could be cognizant of these sorts of things;
and shoud be, in fact.
Sure but IMHO it would be more important to fix bugs like the parser
not correctly using indexes on bigint unless the value is quoted...
I think everyone would agree that not having to use initdb would be
nice but I think there is much more important things to focus on.
Besides if you are upgrading PostgreSQL in a production environment I
would assume there would be an extremely valid reason. If the reason
is big enough to do a major version upgrade then an initdb shouldn't
be all that bad of a requirement.
J
--
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@commandprompt.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
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(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 I'm not going to rehash the arguments I have made before; they are all
archived. Suffice to say you are simply wrong. The number of
complaints over the years shows that there IS a need.
I at no point suggested that there was not a need. I only suggest that
the need may not be as great as some suspect or feel. To be honest -- if
your arguments were the "need" that everyone had... it would have been
implemented some how. It hasn't yet which would suggest that the number
of people that have the "need" at your level is not as great as the
number of people who have different "needs" from PostgreSQL.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
>>>>> "MGF" == Marc G Fournier <sc*****@postgresql.org> writes:
MGF> On Sat, 13 Sep 2003, Lamar Owen wrote: Can eRserver replicate a 7.3.x to a 7.2.x? Or 7.4.x to 7.3.x?
MGF> I thought we were talking about upgrades here?
I'm *really* interested in how eRServer works on migrating from 7.2 to
7.4 (either eRServer 1.2 or 1.3 :-) ) I have hopes of doing this once
7.4 goes gold. More testing for me, I guess.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
>>>>> "JDD" == Joshua D Drake <jd@commandprompt.com> writes:
JDD> Besides if you are upgrading PostgreSQL in a production environment I
JDD> would assume there would be an extremely valid reason. If the reason
JDD> is big enough to do a major version upgrade then an initdb shouldn't
JDD> be all that bad of a requirement.
One of my major reasons to want to move from 7.2 to 7.4 is that I
suffer from incredible index bloat. Reindex on one of my tables takes
about 45 minutes per each of the 3 indexes on it during which time
part of my system is blocked.
Granted, the one-time cost of the migration to 7.4 will probably take
about 5 hours of dump/restore, but at least with the re-indexing I can
do one 45 minute block at a atime stretched over a few days early
in the morning.
I think some sort of scripted migration/upgrade tool that used
eRServer would be way cool.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
On Mon, 15 Sep 2003, Joshua D. Drake wrote: I'm not going to rehash the arguments I have made before; they are all
archived. Suffice to say you are simply wrong. The number of
complaints over the years shows that there IS a need.
I at no point suggested that there was not a need. I only suggest that
the need may not be as great as some suspect or feel. To be honest -- if
your arguments were the "need" that everyone had... it would have been
implemented some how. It hasn't yet which would suggest that the number
of people that have the "need" at your level is not as great as the
number of people who have different "needs" from PostgreSQL.
Just to add to this ... Bruce *did* start pg_upgrade, but I don't recall
anyone else looking at extending it ... if the *need* was so great,
someone would have step'd up and looked into adding to what was already
there ...
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org kh***@kcilink.com (Vivek Khera) writes: >> "MGF" == Marc G Fournier <sc*****@postgresql.org> writes: MGF> On Sat, 13 Sep 2003, Lamar Owen wrote:
Can eRserver replicate a 7.3.x to a 7.2.x? Or 7.4.x to 7.3.x?
MGF> I thought we were talking about upgrades here?
I'm *really* interested in how eRServer works on migrating from 7.2 to
7.4 (either eRServer 1.2 or 1.3 :-) ) I have hopes of doing this once
7.4 goes gold. More testing for me, I guess.
I know that 7.2 to 7.3 is being actively looked at, but you're
presumably not getting straight answers on this because nobody has
FINISHED testing the process.
In any case, if your data is a "big deal" to you, there's no question
of doing some sort of blind "Download it, double click the icon;
accept the license agreement, and convert it all."
eRServer is complex enough critter that you would doubtless want to do
a "dry run" on a pair of test databases in order to make sure you know
what things need to be fiddled with in order to get it right.
There's going to be at least a _little_ bit of an outage involved in
switching the direction of replication between the databases, and you
surely want to do a dry run to let you know _all_ the details so that
you can build a checklist suitable to make sure that Going Live goes
as quickly and smoothly as possible, and to keep that outage as short
as possible.
Unfortunately, there are no "infinite" shortcuts to be had. (Not that
there aren't vendors out there willing to try to sell them... :-))
--
(reverse (concatenate 'string "ofni.smrytrebil" "@" "enworbbc"))
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
On Mon, 2003-09-15 at 14:40, Lamar Owen wrote: Joshua D. Drake wrote: It is alot but is is not a lot for something like an Insurance company
or a bank. Also 100TB is probably non-compressed although 30TB is still
large.
Our requirements are such that this figure is our best guess after
compression. The amount of data prior to compression is much larger,
and consists of highly compressible astronomical observations in FITS
format.
Just MHO, but I'd think about keeping the images outside of the
database (or in a separate database), since pg_dump is single-
threaded, and thus 1 CPU will be hammered trying to compress the
FITS files, while the other CPU(s) sit idle.
Of course, you could compress the images on the front end, saving
disk space and do uncompressed pg_dumps. The pg_dump would be IO
bound, then. But I'm sure you thought of that already...
The images would have to be uncompressed at view time, but that
could happen on the client, thus saving bandwidth, and distributing
CPU needs. http://h18006.www1.hp.com/products/s...000/index.html
This box is pretty spiffy: "up to 119 TB of native capacity",
"Multi-unit scalability supporting up to 64 drives and 2278
cartridges".
Too bad it doesn't mention Linux.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
Great Inventors of our time:
Al Gore -> Internet
Sun Microsystems -> Clusters
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org
On Mon, 2003-09-15 at 14:40, Lamar Owen wrote: Joshua D. Drake wrote: It is alot but is is not a lot for something like an Insurance company
or a bank. Also 100TB is probably non-compressed although 30TB is still
large.
Our requirements are such that this figure is our best guess after
compression. The amount of data prior to compression is much larger,
and consists of highly compressible astronomical observations in FITS
format.
Wow, it just occurred to me: if you partition the data correctly,
you won't need to back it *all* up on a daily/weekly/monthly basis.
Once you back up a chunk of compressed images ("Orion, between 2001-
01-01 and 2001-01-31") a few times, no more need to back that data
up.
Thus, you don't need monster archival h/w like some of us do.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
484,246 sq mi are needed for 6 billion people to live, 4 persons
per lot, in lots that are 60'x150'.
That is ~ California, Texas and Missouri.
Alternatively, France, Spain and The United Kingdom.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
On Mon, 2003-09-15 at 13:24, Joshua D. Drake wrote: Strawmen. If we provide a good upgrade capability, we would just
simply have to think about upgrades before changing features like
that. The upgrade code could be cognizant of these sorts of things;
and shoud be, in fact.
Sure but IMHO it would be more important to fix bugs like the parser not
correctly using indexes on bigint unless the value is quoted...
I think everyone would agree that not having to use initdb would be nice
but I think there is much more important things to focus on.
Besides if you are upgrading PostgreSQL in a production environment I
would assume there would be an extremely valid reason. If the reason is
big enough to do a major version upgrade then an initdb shouldn't be all
that bad of a requirement.
Hmmm. A (US-oriented) hypothetical:
BOSS: The app works now. Why rock the boat?
DBA: The new version has features that will save 20% disk space,
and speed up certain operations by 75% every day.
BOSS: Fantastic! How long will it take to upgrade?
DBA: 18 hours.
BOSS: 18 hours!! We can only take that much downtime on Thanks-
giving weekend, or 3-day July 4th, Christmas or New Year's
weekends.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
"(Women are) like compilers. They take simple statements and
make them into big productions."
Pitr Dubovitch
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
On Mon, 2003-09-15 at 15:23, Joshua D. Drake wrote: I'm not going to rehash the arguments I have made before; they are all
archived. Suffice to say you are simply wrong. The number of
complaints over the years shows that there IS a need.
I at no point suggested that there was not a need. I only suggest that
the need may not be as great as some suspect or feel. To be honest -- if
your arguments were the "need" that everyone had... it would have been
implemented some how. It hasn't yet which would suggest that the number
of people that have the "need" at your level is not as great as the
number of people who have different "needs" from PostgreSQL.
But the problem is that as more and more people put larger and larger
datasets, that are mission-critical, into PostgreSQL, the need will
grow larger and larger.
Of course, we understand the "finite resources" issue, and are not
badgering/complaining. Simply, we are trying to make our case that
this is something that should go on the TODO list, and be kept in
the back of developers' minds.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
"You ask us the same question every day, and we give you the
same answer every day. Someday, we hope that you will believe us..."
U.S. Secretary of Defense Donald Rumsfeld, to a reporter
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org) Hmmm. A (US-oriented) hypothetical:
BOSS: The app works now. Why rock the boat?
DBA: The new version has features that will save 20% disk space,
and speed up certain operations by 75% every day.
BOSS: Fantastic! How long will it take to upgrade?
DBA: 18 hours.
BOSS: 18 hours!! We can only take that much downtime on Thanks-
giving weekend, or 3-day July 4th, Christmas or New Year's
weekends.
Sounds like you just found several weekends a year that you
can do the upgrade with ;). Yes that was a joke.
Sincerley,
Joshua Drake
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
Marc G. Fournier wrote: On Mon, 15 Sep 2003, Joshua D. Drake wrote:I'm not going to rehash the arguments I have made before;
I at no point suggested that there was not a need. I only suggest that
the need may not be as great as some suspect or feel. To be honest -- if
your arguments were the "need" that everyone had... it would have been
implemented some how. It hasn't yet which would suggest that the number
Just to add to this ... Bruce *did* start pg_upgrade, but I don't recall
anyone else looking at extending it ... if the *need* was so great,
someone would have step'd up and looked into adding to what was already
there ...
You'ns are going to make a liar out of me yet; I said I wasn't going to
rehash the arguments. But I am going to answer Marc's statement. Need
of the users != developer interest in implementing those. This is the
ugly fact of open source software -- it is developer-driven, not
user-driven. If it were user-driven in this case seamless upgrading
would have already happened. But the sad fact is that the people who
have the necessary knowledge of the codebase in question are so
complacent and comfortable with the current dump/reload cycle that they
really don't seem to care about the upgrade issue. That is quite a
harsh statement to make, yes, and I know that is kind of
uncharacteristic for me. But, Marc, your statement thoroughy ignores
the archived history of this issue on the lists.
While pg_upgrade was a good first step (and I applaud Bruce for working
on it), it was promptly broken because the developers who changed the
on-disk format felt it wasn't important to make it continue working.
Stepping up to the plate on this issue will require an intimate
knowledge of the storage manager subsystem, a thorough knowledge of the
system catalogs, etc. This has been discussed at length; I'll not
repeat it. Just any old developer can't do this -- it needs the
long-term focused attention of Tom, Jan, or Bruce. And that isn't going
to happen. We know Tom's take on it; it's archived. Maybe there's
someone out there with the deep knowledge of the backend to make this
happen who cares enough about it to make it happen, and who has the time
to do it. I care enough to do the work; but I have neither the deep
knowledge necessary nor the time to make it happen. There are many in
my position. But those who could make it happen don't seem to have the
care level to do so.
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level. While
I know, Marc, how the whole project got started (I have read the first
posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
original core team because you were and are users of PostgreSQL, I
sincerely believe that in this instance you are out of touch with this
need of many of today's userbase. And I say that with full knowledge of
PostgreSQL Inc.'s support role. If given the choice between upgrading
capability, PITR, and Win32 support, my vote would go to upgrading.
Then migrating to PITR won't be a PITN.
What good are great features if it's a PITN to get upgraded to them?
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org
> repeat it. Just any old developer can't do this -- it needs the long-term focused attention of Tom, Jan, or Bruce. And that isn't going
I believe that neither of these people was born with the knowledge of how
PostgreSQL is working. An experienced developer with the time and the money
would be able to solve your problem.
to do it. I care enough to do the work; but I have neither the deep
knowledge necessary nor the time to make it happen. There are many in
You and others state that this is a very important issue. But it's really only
an issue if you can't ever have a service window. If people don't have
service windows, they have very expensive solutions and ought to be able to
afford the expense of a developer. They get so much for free, so if this is
the only problem they have, they should collect and hire a programmer.
my position. But those who could make it happen don't seem to have the
care level to do so.
They're occupied with other matters. And yes - they often choose from personal
interest - and an upgrade tool will never make top 5 for any normal developer
;-)
What good are great features if it's a PITN to get upgraded to them?
I still believe that users who can't upgrade are few and far between. If they
are so many, why won't they sponsor the cost for an upgrade utility ?
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
Kaare Rasmussen wrote: repeat it. Just any old developer can't do this -- it needs the
long-term focused attention of Tom, Jan, or Bruce. And that isn't going
I believe that neither of these people was born with the knowledge of how
PostgreSQL is working. An experienced developer with the time and the money
would be able to solve your problem.
There is a typo in my post; the indefinite article should be prepended
to the list of names; to solve this problem, we need _a_ Tom, Jan, or
Bruce, meaning a core-grade developer with substantial experience in
this codebase.
You and others state that this is a very important issue. But it's really only
an issue if you can't ever have a service window. If people don't have
service windows, they have very expensive solutions and ought to be able to
afford the expense of a developer. They get so much for free, so if this is
the only problem they have, they should collect and hire a programmer.
This is an issue for more than those you state. I have had numerous
complaints as RPM maintainer for the surprise people have when they find
out that PostgreSQL just has to be different from every other package
that they upgrade. But again, the issues are well documented in the
archives, and my patience for people who want to rehash these well
documented things is wearing thin. Tom has said that I have eloquently
stated my side of the argument, which, incidentally, I took as a massive
compliment (many thanks Tom), even though I don't personally feel it was
very eloquent. So read the archives, it is very thoroughly stated
there. But if I must continue restating what I have seen and heard,
then I guess I must.
And there are times dump/restore fails. Read the archives for those times.
It is ludicrous to require dump restore. I'm sorry, but that is my
studied opinion of the matter, over a period of 5 years. nd I don't
care if Oracle or anybody else in the RDBMS field also does this; it is
still ludicrous.
They're occupied with other matters. And yes - they often choose from personal
interest - and an upgrade tool will never make top 5 for any normal developer
;-)
And that's the root of the problem, as I already stated.
I still believe that users who can't upgrade are few and far between. If they
are so many, why won't they sponsor the cost for an upgrade utility ?
Read the archives, and read Red Hat's bugzilla for PostgreSQL before
making blanket unsubstantiated statements like that.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
On Tuesday, September 16, 2003, at 10:18 AM, Kaare Rasmussen wrote: repeat it. Just any old developer can't do this -- it needs the
long-term focused attention of Tom, Jan, or Bruce. And that isn't
going
I believe that neither of these people was born with the knowledge of
how
PostgreSQL is working. An experienced developer with the time and the
money
would be able to solve your problem.
I'll take Tom's word for it that it wouldn't be trivial, so I don't
think its quite so casual as that. I
wouldn't mind stepping up, but doing so would negate the need, as my
business would fail.
to do it. I care enough to do the work; but I have neither the deep
knowledge necessary nor the time to make it happen. There are many in
You and others state that this is a very important issue. But it's
really only
an issue if you can't ever have a service window. If people don't have
service windows, they have very expensive solutions and ought to be
able to
afford the expense of a developer. They get so much for free, so if
this is
the only problem they have, they should collect and hire a programmer.
Having a service window and wanting or being able to use it for
something that is bound
to make people nervous are two different things. And the idea that
people without service
windows having enough money to hire developers is complete fantasy, I'm
sorry.
Look, I'm not pissing and moaning about the developers lack of
attention or anything. They do
an amazing job. I understand the 'scratch the itch' nature of the
development, and the great amount
of progress they've made with what was a huge pile of garbled code. At
the same time,
everyone wants to advocate Postgres as an enterprise-ready system. If
you're going to do that,
you have to acknowledge the stumbling blocks. This is one of them. I
can pretty much guarantee
that I will not be allowed to upgrade several clients' systems unless
there's a real show-stopper,
because once I tell them what I have to do they'll tell me to get lost.
I've already given up on Oracle and DB2, and I'm not going back, so
I'll deal with this situation
as best I can. That and I run a small shop, so I don't need to bow to
politics or services/brand
requirements. A lot of people are not so fortunate, and anything that
can be said against
Postgres (or MySQL, FreeBSD, Linux, JBoss, whatever) becomes a hurdle
when trying to push for it.
my position. But those who could make it happen don't seem to have
the
care level to do so.
They're occupied with other matters. And yes - they often choose from
personal
interest - and an upgrade tool will never make top 5 for any normal
developer
;-)
What good are great features if it's a PITN to get upgraded to them?
I still believe that users who can't upgrade are few and far between.
If they
are so many, why won't they sponsor the cost for an upgrade utility ?
We don't exactly meet for beers every Thursday. In the end, I imagine
it will still take the attention
of one or more of the core developers. If any of them want to be
involved, I don't mind considering the
possibility.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816
2582
Kaki Data tshirts, merchandize Fax: 3816
2501
Howitzvej 75 Åben 12.00-18.00 Email:
ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web:
www.suse.dk
---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
>>>>> "MGF" == Marc G Fournier <sc*****@postgresql.org> writes:
MGF> On Mon, 15 Sep 2003, Joshua D. Drake wrote:
MGF> Just to add to this ... Bruce *did* start pg_upgrade, but I don't recall
MGF> anyone else looking at extending it ... if the *need* was so great,
MGF> someone would have step'd up and looked into adding to what was already
MGF> there ...
Hmmm, this is the math I just did in my head:
time to implement pg_upgrade = X
time to dump/restore once per year = Y
If X > Y*2 then why bother expending the effort? Now, if the X was
distributed over a bunch of people, perhaps it would make sense to me.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(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
>>>>> "JDD" == Joshua D Drake <jd@commandprompt.com> writes: BOSS: 18 hours!! We can only take that much downtime on Thanks-
giving weekend, or 3-day July 4th, Christmas or New Year's
weekends.
JDD> Sounds like you just found several weekends a year that you
JDD> can do the upgrade with ;). Yes that was a joke.
it's not a joke around here!
every major long weekend, late saturday night or early saturday
morning, i log in and run major maintenance such as reindexing. so
far i've only had to do the dump/restore once from 7.1 to 7.2, and
that too happened on a long weekend.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
> If X > Y*2 then why bother expending the effort? Now, if the X was distributed over a bunch of people, perhaps it would make sense to me.
Since
affordability(amount(X)) != amount(X)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read the
first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase. And I say that with
full knowledge of PostgreSQL Inc.'s support role. If given the choice
between upgrading capability, PITR, and Win32 support, my vote would
go to upgrading. Then migrating to PITR won't be a PITN.
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs that
are over and above the 12,000. If we get it done quicker, all the better.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Hmmm, ok, I can't retask any of my people or reallocation funds for this year
but I can personally do 5 to 10% of that monthly cost.
Some more people and project plan- then the ball could roll :)
Quoting "Joshua D. Drake" <jd@commandprompt.com>:
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read the
first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase. And I say that with
full knowledge of PostgreSQL Inc.'s support role. If given the choice
between upgrading capability, PITR, and Win32 support, my vote would
go to upgrading. Then migrating to PITR won't be a PITN.
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs that
are over and above the 12,000. If we get it done quicker, all the better.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc. http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
---------------------------(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
Let me run some numbers. I'm interested in the idea, and I think I can
push one of my clients on it.
Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
sort of time commitment? Is it maintainable over time? Or are we
pissing in the wind?
On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read
the first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase. And I say that with
full knowledge of PostgreSQL Inc.'s support role. If given the
choice between upgrading capability, PITR, and Win32 support, my vote
would go to upgrading. Then migrating to PITR won't be a PITN.
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs
that are over and above the 12,000. If we get it done quicker, all the
better.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of
broadcast)---------------------------
TIP 8: explain analyze is your friend
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org) And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read the
first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase.
Huh? I have no disagreement that upgrading is a key feature that we are
lacking ... but, if there are any *on disk* changes between releases, how
do you propose 'in place upgrades'? Granted, if its just changes to the
system catalogs and such, pg_upgrade should be able to be taught to handle
it .. I haven't seen anyone step up to do so, and for someone spending so
much time pushing for an upgrade path, I haven't seen you pony up the time
....
Just curious here ... but, with all the time you've spent pushing for an
"easy upgrade path", have you looked at the other RDBMSs and how they deal
with upgrades? I think its going to be a sort of apples-to-oranges thing,
since I imagine that most of the 'big ones' don't change their disk
formats anymore ...
What I'd be curious about is how badly we compare as far as major releases
are concerned ... I don't believe we've had a x.y.z release yet that
required a dump/reload (and if so, it was a very very special
circumstance), but what about x.y releases? In Oracle's case, i don't
think they do x.y.z releases, do they? Only X and x.y?
K, looking back through that it almost sounds like a ramble ... hopefully
you understand what I'm asking ...
I know when I was at the University, and they dealt with Oracle upgrades,
the guys plan'd for a weekend ...
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Lamar Owen wrote: And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level. While
I know, Marc, how the whole project got started (I have read the first
posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
original core team because you were and are users of PostgreSQL, I
sincerely believe that in this instance you are out of touch with this
need of many of today's userbase. And I say that with full knowledge of
PostgreSQL Inc.'s support role. If given the choice between upgrading
capability, PITR, and Win32 support, my vote would go to upgrading. Then
migrating to PITR won't be a PITN.
Ouch. I'd like to see an easy upgrade path, but I'd rather have a 7.5
with PITR then an in-place upgrade. Perhaps the demand for either is
associated with the size of the db vs. the fear associated with an
inability to restore to a point-in-time. My fear of an accidental:
DELETE FROM foo;
is greater than my loathing of the upgrade process.
What good are great features if it's a PITN to get upgraded to them?
What good is an in-place upgrade without new features?
(I'm kinda joking here) ;-)
Mike Mascari ma*****@mascari.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
It's be EXTREMELY cool if there was some relationship betweenn the code for;
PITR and
Inplace upgrades
Any possibility of overlaps?
Mike Mascari wrote: Lamar Owen wrote:
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level. While
I know, Marc, how the whole project got started (I have read the first
posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
original core team because you were and are users of PostgreSQL, I
sincerely believe that in this instance you are out of touch with this
need of many of today's userbase. And I say that with full knowledge of
PostgreSQL Inc.'s support role. If given the choice between upgrading
capability, PITR, and Win32 support, my vote would go to upgrading. Then
migrating to PITR won't be a PITN.
Ouch. I'd like to see an easy upgrade path, but I'd rather have a 7.5
with PITR then an in-place upgrade. Perhaps the demand for either is
associated with the size of the db vs. the fear associated with an
inability to restore to a point-in-time. My fear of an accidental:
DELETE FROM foo;
is greater than my loathing of the upgrade process.
What good are great features if it's a PITN to get upgraded to them?
What good is an in-place upgrade without new features?
(I'm kinda joking here) ;-)
Mike Mascari
ma*****@mascari.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
As I understand it, changes that require the dump restore fall into two
categories, catalog changes, and on disk format changes. If that's the
case (I'm as likely wrong as right here, I know) then it could be that
most upgrades (say 7.4 to 7.5) could be accomplished more easier than the
occasional ones that require actual disk format changes (i.e. 7.5 to 8.0)
If that's the case, I'd imagine that as postgresql gets more mature, on
disk upgrades should become easier to implement, and dump/restore would
only be required for major version upgrades at some point.
Is that about right, and if so, would it make maintaining this kind of
program simpler if it only had to handle catalog changes?
On Tue, 16 Sep 2003, Andrew Rawnsley wrote:
Let me run some numbers. I'm interested in the idea, and I think I can
push one of my clients on it.
Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
sort of time commitment? Is it maintainable over time? Or are we
pissing in the wind?
On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read
the first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase. And I say that with
full knowledge of PostgreSQL Inc.'s support role. If given the
choice between upgrading capability, PITR, and Win32 support, my vote
would go to upgrading. Then migrating to PITR won't be a PITN.
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs
that are over and above the 12,000. If we get it done quicker, all the
better.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of
broadcast)---------------------------
TIP 8: explain analyze is your friend
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
---------------------------(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
On Tuesday, September 16, 2003, at 04:51 PM, Marc G. Fournier wrote:
Just curious here ... but, with all the time you've spent pushing for
an
"easy upgrade path", have you looked at the other RDBMSs and how they
deal
with upgrades? I think its going to be a sort of apples-to-oranges
thing,
since I imagine that most of the 'big ones' don't change their disk
formats anymore ...
That's probably the thing - they've written the on-disk stuff in stone
by now. DB2 has
a lot of function rebinding to do, but thats probably a different issue.
Tying to my last post, concerning Joshua's offer to put up the labor if
we can put up the dough, given the
fact that Postgres is still in flux, do you think its even possible to
do some sort of in-place upgrade, not knowing
what may come up when you're writing 7.6?
In other words, if we pony up and get something written now, will it
need further development every time an x.y release comes up.
What I'd be curious about is how badly we compare as far as major
releases
are concerned ... I don't believe we've had a x.y.z release yet that
required a dump/reload (and if so, it was a very very special
circumstance), but what about x.y releases? In Oracle's case, i don't
think they do x.y.z releases, do they? Only X and x.y?
Lord, who knows what they're up to. They do (or did) x.y.z releases
(I'm using 8.1.6), but publicly they're
calling everything 8i,9i,10g yahdah yahdah yahdah.
I certainly will concede that (to me), upgrading Postgres is easier
than Oracle, as I can configure, compile, install,
do an initdb, and generate an entire large DDL in the time it takes the
abysmal Oracle installer to even start. Then try
to install/upgrade it on an 'unsupported' linux, like Slack...but I
don't have to do anything with the data.
To a PHB/PHC (pointy-haired-client), saying 'Oracle' is like giving
them a box of Depends, even though it doesn't save them
from a fire hose. They feel safe.
K, looking back through that it almost sounds like a ramble ...
hopefully
you understand what I'm asking ...
I know when I was at the University, and they dealt with Oracle
upgrades,
the guys plan'd for a weekend ...
---------------------------(end of
broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Hello,
I would imagine that it would be maintainable but it would be
something that would have to be
constantly maintained from release to release. It would have to become
part of the actual project or
it would die.
The reason I chose six months is that I figure it will be 30 days of
full time just dinking around to make
sure that we have a solid handle on how things are done for this part of
the code. Then we would know
what we think it would take. It was a gut theory but I believe it can be
done or at least a huge jump on it.
Sincerely,
Joshua Drake
Andrew Rawnsley wrote:
Let me run some numbers. I'm interested in the idea, and I think I can
push one of my clients on it.
Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
sort of time commitment? Is it maintainable over time? Or are we
pissing in the wind?
On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read
the first posts), and I appreciate that you, Bruce, Thomas, and
Vadim started the original core team because you were and are users
of PostgreSQL, I sincerely believe that in this instance you are out
of touch with this need of many of today's userbase. And I say that
with full knowledge of PostgreSQL Inc.'s support role. If given the
choice between upgrading capability, PITR, and Win32 support, my
vote would go to upgrading. Then migrating to PITR won't be a PITN.
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task.
So if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs
that are over and above the 12,000. If we get it done quicker, all
the better.
Sincerely,
Joshua Drake
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(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 Tying to my last post, concerning Joshua's offer to put up the labor
if we can put up the dough, given the
fact that Postgres is still in flux, do you think its even possible to
do some sort of in-place upgrade, not knowing
what may come up when you're writing 7.6?
In other words, if we pony up and get something written now, will it
need further development every time an x.y release comes up.
There is probably no question that it will need further development.
However, I would imagine that once the intial grunt work is done it
would be much easier to migrate the code (especially if it is
continually maintained) to newer releases.
My thought process is that we would start with 7.4 codebase and as it
migrates to 7.5 move the work directly to 7.5 and if possible release
for 7.5 (although that really may be pushing it).
J
What I'd be curious about is how badly we compare as far as major
releases
are concerned ... I don't believe we've had a x.y.z release yet that
required a dump/reload (and if so, it was a very very special
circumstance), but what about x.y releases? In Oracle's case, i don't
think they do x.y.z releases, do they? Only X and x.y?
Lord, who knows what they're up to. They do (or did) x.y.z releases
(I'm using 8.1.6), but publicly they're
calling everything 8i,9i,10g yahdah yahdah yahdah.
I certainly will concede that (to me), upgrading Postgres is easier
than Oracle, as I can configure, compile, install,
do an initdb, and generate an entire large DDL in the time it takes
the abysmal Oracle installer to even start. Then try
to install/upgrade it on an 'unsupported' linux, like Slack...but I
don't have to do anything with the data.
To a PHB/PHC (pointy-haired-client), saying 'Oracle' is like giving
them a box of Depends, even though it doesn't save them
from a fire hose. They feel safe.
K, looking back through that it almost sounds like a ramble ...
hopefully
you understand what I'm asking ...
I know when I was at the University, and they dealt with Oracle
upgrades,
the guys plan'd for a weekend ...
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(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
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprompt.com> uttered something amazingly similar to: If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs that
are over and above the 12,000. If we get it done quicker, all the better.
Well, if you're willing to set up some sort of escrow, I'll put in $100. I
don't do db's except for play, but I hate the dump/restore part. I've lost data
two times fat-fingering the upgrade, trying to use two running installations on
the same machine. I'm that good...
Cheers,
Rob
--
21:28:34 up 46 days, 14:03, 4 users, load average: 2.00, 2.00, 2.00
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iEYEARECAAYFAj9n1mcACgkQgy51bQc2FFkTZgCgmYhKAD7BTM x/HLrBpHgqvDWe
wiEAoMGcWzsR4O+DBBLjxUC36eaNrhUt
=b9c5
-----END PGP SIGNATURE-----
Robert Creager wrote: Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprompt.com> uttered something amazingly similar to:
If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs that
are over and above the 12,000. If we get it done quicker, all the better.
Well, if you're willing to set up some sort of escrow, I'll put in $100. I
don't do db's except for play, but I hate the dump/restore part. I've lost data
two times fat-fingering the upgrade, trying to use two running installations on
the same machine. I'm that good...
Cheers,
Rob
Is that $100 times once, or $100 X 6mos anticiapated develop time.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Andrew Rawnsley <ro**@ravensfield.com> writes: On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote: If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task.
Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
sort of time commitment?
While I dislike staring gift horses in the mouth, I have to say that
the people I think could do it (a) are getting paid more than $24K/yr,
and (b) are names already seen regularly in the PG commit logs. If
there's anyone in category (b) who works for Command Prompt, I missed
the connection.
I have no doubt that a competent programmer could learn the Postgres
innards well enough to do the job; as someone pointed out earlier in
this thread, none of the core committee was born knowing Postgres.
I do, however, doubt that it can be done in six months if one has
any significant learning curve to climb up first.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
>> If someone is willing to pony up 2000.00 per month for a period of at least 6 months, I will dedicated one of my programmers to the task.
I stated the "how much will it cost" question, but I'm beginning to think that
it's the wrong approach. From the answers in this thread I do believe that it
will be an eternal chase with almost certainty of errors.
Some people have claimed that the big commercial databases don't change their
on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
goal. At least try to get the on-disk changes ready for 7.5 - with or without
the functionality to use it. I think that any pg_* table changes could be
done with a small and efficient pg_upgrade.
Big items that will change the way PostgreSQL stores its data would be
Tablespaces
PITR
....
More ?
I know it's not possible to tell the future, but if Oracle is steady,
shouldn't it be possible?
How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
FireBird ??
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
---------------------------(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
On Wed, 17 Sep 2003, Kaare Rasmussen wrote:
How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
FireBird ??
Well MySql for one has more than one on-disk format....
One that supports transactions and one that does not. Looks like they do
it my writting different tables in different ways. A very stupid thing to
do if you ask me.
Peter Childs
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
On Wed, 17 Sep 2003, Kaare Rasmussen wrote: I know it's not possible to tell the future, but if Oracle is steady,
shouldn't it be possible?
Also consider that Oracle has 'the big bucks' to dedicate a group of staff
to keep on top of the upgrade issues ...
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
On Wed, 2003-09-17 at 03:45, Kaare Rasmussen wrote:
[snip] Some people have claimed that the big commercial databases don't change their
on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
goal. At least try to get the on-disk changes ready for 7.5 - with or without
the functionality to use it. I think that any pg_* table changes could be
done with a small and efficient pg_upgrade.
[snip]
I think changes in the system catalog should be separated from
changes in the physical on-disk structures (i.e. how tables and
indexes are stored).
Maybe I'm totally wrong, but ALTERing the pg_* tables during each
version upgrade should be relatively easy to script, when the phys-
ical on-disk structures have been solidified.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
The difference between drunken sailors and Congressmen is that
drunken sailors spend their own money.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <ge*****@fireserve.net> uttered something amazingly similar to: Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprompt.com> uttered something amazingly similar
to:
If someone is willing to pony up 2000.00 per month for a period of at
Well, if you're willing to set up some sort of escrow, I'll put in $100. I
Is that $100 times once, or $100 X 6mos anticiapated develop time.
That's $100 once. And last I looked, there are well over 1800 subscribers on
this list alone. On the astronomically small chance everyone one of them did
what I'm doing, it would cover more than 6 months of development time ;-) This
strikes me as like supporting public radio. The individuals do some, and the
corporations do a bunch.
I'm just putting my money toward a great product, rather than complaining that
it's not done. Just like Joshua is doing. You cannot hire a competent
programmer for $24k a year, so he is putting up some money on this also.
There have been a couple of other bytes from small businesses, so who knows!
You game?
Cheers,
Rob
--
07:47:48 up 47 days, 22 min, 4 users, load average: 2.04, 2.07, 2.02
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iEYEARECAAYFAj9oaQMACgkQgy51bQc2FFkqBACePh8QTq76Tu ZfPCAywuEo2f9r
8ksAn2XlhaoMyepC2zkHKyJ6oZS9XjaK
=+o0P
-----END PGP SIGNATURE-----
This is along the lines of what I was talking about. If at compile time a user
could chose their on disk representation by version within a reasonable history
(say two major versions back) then I that would give people a choice for a
certain about of time.
Backward compatibility is nice but at a certain point it will become "backward"
(or better yet awkward or maybe just damn near impossible) to support certain
past features.
This is a user reality, upgrades are part of owning and using any system. Its
just that we don't want to seemingly force people to upgrade. I don't think
that is hard for someone that 24/7 shop with very large databases to understand.
Quoting Ron Johnson <ro***********@cox.net>: On Wed, 2003-09-17 at 03:45, Kaare Rasmussen wrote:
[snip] Some people have claimed that the big commercial databases don't change
their on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
goal. At least try to get the on-disk changes ready for 7.5 - with or
without the functionality to use it. I think that any pg_* table changes could be
done with a small and efficient pg_upgrade.
[snip]
I think changes in the system catalog should be separated from
changes in the physical on-disk structures (i.e. how tables and
indexes are stored).
Maybe I'm totally wrong, but ALTERing the pg_* tables during each
version upgrade should be relatively easy to script, when the phys-
ical on-disk structures have been solidified.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA
The difference between drunken sailors and Congressmen is that
drunken sailors spend their own money.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc. http://vcsn.com
____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
Ron Johnson <ro***********@cox.net> writes: I think changes in the system catalog should be separated from
changes in the physical on-disk structures (i.e. how tables and
indexes are stored).
We already know how to cope with changes in the system catalogs ---
pg_upgrade has pretty much proved out how to do that. The original
shell-script implementation wasn't bulletproof enough for production use
(IMHO anyway), but that's because it was an experimental prototype, not
because there was anything fundamentally wrong with the concept.
The hard part is dealing with mostly-unforeseeable future changes in
our needs for representation of user data. We can and already have done
some simple things like include version numbers in page headers, but it
would be a fatal mistake to suppose that that means the problem is
solved, or that actually doing in-place upgrades won't require a
tremendous amount of additional work.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org
Kaare Rasmussen <ka*@kakidata.dk> writes: Some people have claimed that the big commercial databases don't change their
on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
goal.
At the very least we could try to quantize changes --- say, allow
on-disk changes only every third or fourth major release, and batch up
work requiring such changes. Avoiding on-disk changes actually was a
design consideration for awhile, but we sort of stopped worrying about
it when the prototype version of pg_upgrade stopped working (which IIRC
was because it couldn't get at what it would need to get at without
being rewritten in C, and no one wanted to tackle that project).
How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
FireBird ??
Dunno about MySQL. I'm pretty sure I remember Ann Harrison stating that
FireBird's disk structures haven't changed since the beginning of
Interbase. Which you might take as saying that they were a lot smarter
than we are, but I suspect what it really means is that
FireBird/Interbase hasn't undergone the kind of metamorphosis of purpose
that the Postgres code base has. Keep in mind that it started as an
experimental academic prototype (representing some successful ideas and
some not-so-successful ones), and the current developers have been
laboring to convert it into an industrial-strength production tool ---
keeping the good experimental ideas, but weeding out the bad ones, and
adding production-oriented features that weren't in the original design.
The entire argument that version-to-version stability should be a
critical goal would have been foreign to the original developers of
Postgres.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org I have no doubt that a competent programmer could learn the Postgres
innards well enough to do the job; as someone pointed out earlier in
this thread, none of the core committee was born knowing Postgres.
I do, however, doubt that it can be done in six months if one has
any significant learning curve to climb up first.
Hello,
This is a completely reasonable statement. However we have
three full time programmers right now that are fairly familiar with
the internals of PostgreSQL. They are the programmers that
are currently coding our transactional replication engine (which
is going beta in about 3 weeks), plPHP, and also did the work on
S/ODBC, S/JDBC and PgManage.
I am not going to say that we are neccessarily Tom Lane material ;)
but my programmers are quite good and learning more everyday. They
have been in the guts of PostgreSQL for 9 months straight, 40 hours
a week now.
Sincerely,
Joshua Drake
regards, tom lane
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
I had already committed $50/mo.
Robert Creager wrote: Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <ge*****@fireserve.net> uttered something amazingly similar to:
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprompt.com> uttered something amazingly similar
to:
If someone is willing to pony up 2000.00 per month for a period of at
Well, if you're willing to set up some sort of escrow, I'll put in $100. I
Is that $100 times once, or $100 X 6mos anticiapated develop time.
That's $100 once. And last I looked, there are well over 1800 subscribers on
this list alone. On the astronomically small chance everyone one of them did
what I'm doing, it would cover more than 6 months of development time ;-) This
strikes me as like supporting public radio. The individuals do some, and the
corporations do a bunch.
I'm just putting my money toward a great product, rather than complaining that
it's not done. Just like Joshua is doing. You cannot hire a competent
programmer for $24k a year, so he is putting up some money on this also.
There have been a couple of other bytes from small businesses, so who knows!
You game?
Cheers,
Rob
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Hello,
O.k. here are my thoughts on how this could work:
Command Prompt will set up an escrow account online at www.escrow.com.
When the Escrow account totals 2000.00 and is released, Command Prompt
will dedicate a
programmer for one month to debugging, documenting, reviewing,
digging, crying,
screaming, begging and bleeding with the code. At the end of the month
and probably during
depending on how everything goes Command Prompt will release its
findings. The findings
will include a project plan on moving forward over the next 5 months
(if that is what it takes) to
produce the first functional pg_upgrade.
If the project is deemed as moving in the right direction by the
community members and specifically
the core members we will setup milestone payments for the project.
What does everyone think?
Sincerely,
Joshua D. Drake
Dennis Gearon wrote: I had already committed $50/mo.
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <ge*****@fireserve.net> uttered something amazingly
similar to:
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprompt.com> uttered something
amazingly similar
to:
> If someone is willing to pony up 2000.00 per month for a period of
> at
Well, if you're willing to set up some sort of escrow, I'll put in
$100. I
Is that $100 times once, or $100 X 6mos anticiapated develop time.
That's $100 once. And last I looked, there are well over 1800
subscribers on
this list alone. On the astronomically small chance everyone one of
them did
what I'm doing, it would cover more than 6 months of development time
;-) This
strikes me as like supporting public radio. The individuals do some,
and the
corporations do a bunch.
I'm just putting my money toward a great product, rather than
complaining that
it's not done. Just like Joshua is doing. You cannot hire a competent
programmer for $24k a year, so he is putting up some money on this also.
There have been a couple of other bytes from small businesses, so who
knows!
You game?
Cheers,
Rob
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Hi, Command Prompt will set up an escrow account online at www.escrow.com.
When the Escrow account totals 2000.00 and is released, Command Prompt
will dedicate a programmer for one month to debugging, documenting,
reviewing, digging, crying, screaming, begging and bleeding with the
code. At the end of the month and probably during depending on how
everything goes Command Prompt will release its findings. The findings
will include a project plan on moving forward over the next 5 months
(if that is what it takes) to produce the first functional pg_upgrade.
If the project is deemed as moving in the right direction by the
community members and specifically the core members we will setup
milestone payments for the project.
What does everyone think?
Sounds good. It provides a safe way for people to fund this development. I
can't promise anything yet on behalf of my company, but I'll donate at least
$50,- personally.
Sander.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Hello,
Yes that would be expected. I was figuring the first 2k would be the
diagnostics/development
of that plan so that we would have a real idea of what the programmers
think it would take. Thus
the statement of the next 5 months etc..
J
Network Administrator wrote: That sounds good save two things. We need to state what are the project run
dates and what happens at or around the due date. That to say we have the
deliverable for testing (beta ready), more time is needed to complete core
features (alpha ready) and therefore more funds are needed, project is one hold
due to features needed outside the scope of the project, etc, etc, etc...
You get the idea.
Quoting "Joshua D. Drake" <jd@commandprompt.com>:
Hello,
O.k. here are my thoughts on how this could work:
Command Prompt will set up an escrow account online at www.escrow.com.
When the Escrow account totals 2000.00 and is released, Command Prompt
will dedicate a
programmer for one month to debugging, documenting, reviewing,
digging, crying,
screaming, begging and bleeding with the code. At the end of the month
and probably during
depending on how everything goes Command Prompt will release its
findings. The findings
will include a project plan on moving forward over the next 5 months
(if that is what it takes) to
produce the first functional pg_upgrade.
If the project is deemed as moving in the right direction by the
community members and specifically
the core members we will setup milestone payments for the project.
What does everyone think?
Sincerely,
Joshua D. Drake
Dennis Gearon wrote:
I had already committed $50/mo.
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <ge*****@fireserve.net> uttered something amazingly
similar to:
>Robert Creager wrote:
>
>
>
>
>
>>Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
>>"Joshua D. Drake" <jd@commandprompt.com> uttered something
>>amazingly similar
>>to:
>>
>>
>>
>>
>>
>>
>>
>>>If someone is willing to pony up 2000.00 per month for a period of
>>>at
>>>
>>>
>>Well, if you're willing to set up some sort of escrow, I'll put in
>>$100. I
>>
>>
>>
>Is that $100 times once, or $100 X 6mos anticiapated develop time.
>
>
>
That's $100 once. And last I looked, there are well over 1800
subscribers on
this list alone. On the astronomically small chance everyone one of
them did
what I'm doing, it would cover more than 6 months of development time
;-) This
strikes me as like supporting public radio. The individuals do some,
and the
corporations do a bunch.
I'm just putting my money toward a great product, rather than
complaining that
it's not done. Just like Joshua is doing. You cannot hire a competent
programmer for $24k a year, so he is putting up some money on this also.
There have been a couple of other bytes from small businesses, so who
knows!
You game?
Cheers,
Rob
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Sounds good to me. I can throw in $500 to start.
On Wednesday, September 17, 2003, at 12:06 PM, Joshua D. Drake wrote: Hello,
O.k. here are my thoughts on how this could work:
Command Prompt will set up an escrow account online at www.escrow.com.
When the Escrow account totals 2000.00 and is released, Command
Prompt will dedicate a
programmer for one month to debugging, documenting, reviewing,
digging, crying,
screaming, begging and bleeding with the code. At the end of the
month and probably during
depending on how everything goes Command Prompt will release its
findings. The findings
will include a project plan on moving forward over the next 5 months
(if that is what it takes) to
produce the first functional pg_upgrade.
If the project is deemed as moving in the right direction by the
community members and specifically
the core members we will setup milestone payments for the project.
What does everyone think?
Sincerely,
Joshua D. Drake
Dennis Gearon wrote:
I had already committed $50/mo.
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <ge*****@fireserve.net> uttered something amazingly
similar to:
Robert Creager wrote:
> Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
> "Joshua D. Drake" <jd@commandprompt.com> uttered something
> amazingly similar
> to:
>
>
>
>
>> If someone is willing to pony up 2000.00 per month for a period
>> of at
>
> Well, if you're willing to set up some sort of escrow, I'll put in
> $100. I
>
Is that $100 times once, or $100 X 6mos anticiapated develop time.
That's $100 once. And last I looked, there are well over 1800
subscribers on
this list alone. On the astronomically small chance everyone one of
them did
what I'm doing, it would cover more than 6 months of development
time ;-) This
strikes me as like supporting public radio. The individuals do
some, and the
corporations do a bunch.
I'm just putting my money toward a great product, rather than
complaining that
it's not done. Just like Joshua is doing. You cannot hire a
competent
programmer for $24k a year, so he is putting up some money on this
also.
There have been a couple of other bytes from small businesses, so
who knows!
You game?
Cheers,
Rob
--
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@commandprompt.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.
---------------------------(end of
broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
Marc G. Fournier wrote: And that has nothing to do with user need as a whole, since the care
level I mentioned is predicated by the developer interest level.
While I know, Marc, how the whole project got started (I have read the
first posts), and I appreciate that you, Bruce, Thomas, and Vadim
started the original core team because you were and are users of
PostgreSQL, I sincerely believe that in this instance you are out of
touch with this need of many of today's userbase.
Huh? I have no disagreement that upgrading is a key feature that we are
lacking ... but, if there are any *on disk* changes between releases, how
do you propose 'in place upgrades'?
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
would be a much happier camper. I would be happy for a migration tool
that could read the old format _without_a_running_old_backend_ and
convert it to the new format _without_a_running_backend_. That's always
been my beef, that the new backend is powerless to recover the old data.
OS upgrades where PostgreSQL is part of the OS, FreeBSD ports upgrades
(according to a user report on the lists a few months back), and RPM
upgrades are absolutely horrid at this point. *You* might can stand it;
some cannot.
Granted, if its just changes to the system catalogs and such, pg_upgrade should be able to be taught to handle
it .. I haven't seen anyone step up to do so, and for someone spending so
much time pushing for an upgrade path, I haven't seen you pony up the time
I believe I pony up quite a bit of time already, Marc. Not as much as
some, by any means, but I am not making one red cent doing what I do for
the project. And one time I was supposed to have gotten paid for a
related project, I didn't. I did get paid by Great Bridge for RPM work
as a one-shot deal, though.
The time I've already spent on this is too much. I've probably put
several hundred hours of my time into this issue in one form or another;
what I don't have time to do is climb the steep slope Tom mentioned
earlier. I actually need to feed my family, and my employer has more
for me to do than something that should have already been done.
Just curious here ... but, with all the time you've spent pushing for an
"easy upgrade path", have you looked at the other RDBMSs and how they deal
with upgrades? I think its going to be a sort of apples-to-oranges thing,
since I imagine that most of the 'big ones' don't change their disk
formats anymore ...
I don't use the others; thus I don't care how they do it; only how we do
it. But even MySQL has a better system than we -- they allow you to
migrate table by table, gaining the new features of the new format when
you migrate. Tom and I pretty much reached consensus that the reason we
have a problem with this is the integration of features in the system
catalogs, and the lack of separation between 'system' information in the
catalogs and 'feature' or 'user' information in the catalogs. It's all
in the archives that nobdy seems willing to read over again. Why do we
even have archives if they're not going to be used?
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.
K, looking back through that it almost sounds like a ramble ... hopefully
you understand what I'm asking ...
*I* should complain about a ramble? :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
Formerly of WGCR Internet Radio, and the PostgreSQL RPM maintainer since
1999.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
On Thu, 18 Sep 2003, Lamar Owen wrote: Huh? I have no disagreement that upgrading is a key feature that we are
lacking ... but, if there are any *on disk* changes between releases, how
do you propose 'in place upgrades'?
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.
'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 ...
See: http://archives.postgresql.org/pgsql...9/msg00886.php
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
On Thursday, September 18, 2003, at 12:11 PM, Lamar Owen wrote:
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 would be a much happier camper. I would be happy for a
migration tool that could read the old format
_without_a_running_old_backend_ and convert it to the new format
_without_a_running_backend_. That's always been my beef, that the new
backend is powerless to recover the old data. OS upgrades where
PostgreSQL is part of the OS, FreeBSD ports upgrades (according to a
user report on the lists a few months back), and RPM upgrades are
absolutely horrid at this point. *You* might can stand it; some > cannot.
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.
Its not a bad idea to do it that way, if you aren't dealing with large
or very complex databases. The first thing its going to do when you add
a slave is do a dump/restore to create the replication target. If you
can afford the disk space and time, that will migrate the data. By
itself that isn't any different than doing that by hand. Where eRserver
may help is keeping the data in sync while you work the other things
out.
Sequences and schemas are the two things it doesn't handle at the
moment. I've created a patch and some new client apps to manage the
schema part, but I haven't had the chance to send them off to someone
to see if they'll fit in. Sequences are on my list of things to do
next. Time time time time.....
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.
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114 www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Eric Raymond |
last post by:
When installing the rpms (or the tar file) onto Red Hat Enteprise
Linux AS Beta 1 (Taroon), we get the follwing error:
Installing all prepared...
|
by: Andrew Rawnsley |
last post by:
Anyone out there using beta 2 in production situations? Comments on
stability? I am rolling out a project in the next 4 weeks, and really
don't...
|
by: Chad Crowder |
last post by:
I've taken a look at this article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp
which someone...
|
by: Kevin Davidson |
last post by:
I am trying to get a clean installation of the .NET framework 1.1 on
Windows 2000 Professional. I had previously installed a beta of the 2.0...
|
by: alundi |
last post by:
Greetings:
I'd like to post this as a new thread to an article in
microsoft.public.dotnet.languages.vb originally made by nevin and replied to...
|
by: Shell |
last post by:
Hi All,
We have an application that uses SQL Server 2000 for State Management data.
We previously use to build and deploy this application using...
|
by: Steve Thompson |
last post by:
Hello all,
I was wondering the differnced there were betwee Active State's python and
the open source version of python. Would I have to unistall...
|
by: Nathan Sokalski |
last post by:
I am recieving the following error on the second postback of a page I have
written:
The state information is invalid for this page and might be...
|
by: Anson.Stuggart |
last post by:
I'm designing a debounce filter using Finite State Machine. The FSM
behavior is it follows the inital input bit and thinks that's real
output until...
|
by: Kemmylinns12 |
last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and...
|
by: Naresh1 |
last post by:
What is WebLogic Admin Training?
WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge...
|
by: AndyPSV |
last post by:
HOW CAN I CREATE AN AI with an .executable file that would suck all files in the folder and on my computerHOW CAN I CREATE AN AI with an .executable...
|
by: WisdomUfot |
last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific...
|
by: Matthew3360 |
last post by:
Hi,
I have been trying to connect to a local host using php curl. But I am finding it hard to do this. I am doing the curl get request from my web...
|
by: Oralloy |
last post by:
Hello Folks,
I am trying to hook up a CPU which I designed using SystemC to I/O pins on an FPGA.
My problem (spelled failure) is with the...
|
by: Carina712 |
last post by:
Setting background colors for Excel documents can help to improve the visual appeal of the document and make it easier to read and understand....
|
by: BLUEPANDA |
last post by:
At BluePanda Dev, we're passionate about building high-quality software and sharing our knowledge with the community. That's why we've created a SaaS...
|
by: Rahul1995seven |
last post by:
Introduction:
In the realm of programming languages, Python has emerged as a powerhouse. With its simplicity, versatility, and robustness, Python...
| |
