On Sunday 28 September 2003 09:36, Ron Johnson wrote:
On Sat, 2003-09-27 at 22:19, Dennis Gearon wrote:
Ron Johnson wrote:
There's always the general point that C has more pitfalls (mainly
from pointers/free()/malloc(), and HLLs do more for you, thus you
have to code less, and,
On Sat, Sep 27, 2003 at 10:42:02PM -0300, Marc G. Fournier wrote:
On Sat, 27 Sep 2003, Ron Johnson wrote:
Isn't Perl pretty ubiquitous on Unix now, though? Except maybe
Unixware
I know that Solaris now has it included by default ...
FWIW, FreeBSD just removed it (in the 5.x
On Sat, 2003-09-27 at 16:50, Nigel J. Andrews wrote:
On Sat, 27 Sep 2003, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
With all the discussion and pg_upgrade, I saw no one offer to work on
it.
Does someone want to convert it to Perl? I think
On Sat, 27 Sep 2003, Ron Johnson wrote:
Isn't Perl pretty ubiquitous on Unix now, though? Except maybe
Unixware
I know that Solaris now has it included by default ...
---(end of broadcast)---
TIP 8: explain analyze is your friend
perl ships on UnixWare (5.005, but that will change in UP3).
LER
--On Saturday, September 27, 2003 22:42:02 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Sat, 27 Sep 2003, Ron Johnson wrote:
Isn't Perl pretty ubiquitous on Unix now, though? Except maybe
Unixware
I know that
$$$ -- I wasn't looking to purchase a programmer. :-)
Well sometimes it takes money to get things done. Personally I don't see
a big need
for pg_upgrade but there was enough people making noise about it that it
made sense
to make the proposal. Several people did come back and offer to cough
On Saturday 27 September 2003 09:45 pm, Joshua D. Drake wrote:
$$$ -- I wasn't looking to purchase a programmer. :-)
Well sometimes it takes money to get things done. Personally I don't see
a big need
for pg_upgrade but there was enough people making noise about it that it
made sense
to
On Sat, 27 Sep 2003, Larry Rosenman wrote:
perl ships on UnixWare (5.005, but that will change in UP3).
In what way? :) It won't ship anymore ... or upgraded?
LER
--On Saturday, September 27, 2003 22:42:02 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Sat, 27 Sep 2003, Ron
--On Sunday, September 28, 2003 00:14:18 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Sat, 27 Sep 2003, Larry Rosenman wrote:
perl ships on UnixWare (5.005, but that will change in UP3).
In what way? :) It won't ship anymore ... or upgraded?
upgraded to 5.8.0
(sorry, should have
Ron Johnson wrote:
There's always the general point that C has more pitfalls (mainly
from pointers/free()/malloc(), and HLLs do more for you, thus you
have to code less, and, consequently, there are fewer bugs.
Someday, they're going to make a langauge called:
CBC, C Bounds Checked
No buffer
On Sat, 2003-09-27 at 22:19, Dennis Gearon wrote:
Ron Johnson wrote:
There's always the general point that C has more pitfalls (mainly
from pointers/free()/malloc(), and HLLs do more for you, thus you
have to code less, and, consequently, there are fewer bugs.
Someday, they're going to
Ron Johnson [EMAIL PROTECTED] writes:
Tom Lane wrote:
The reason that it needs to be rewritten in C is that it needs access to
internal stuff that the backend doesn't expose. (For example, the
transaction counter, end-of-WAL pointer, etc.) I don't think Perl would
offer
On Thu, Sep 18, 2003 at 06:49:56PM -0300, Marc G. Fournier wrote:
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
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; 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
Also, to be blunt: if pg_dump still has problems after all the years
we've put into it, what makes you think that in-place upgrade will
magically work reliably?
Fair enough. On another front then... would all this energy we are
talking about with pg_upgrade
be better spent on
Tom Lane wrote:
Kaare Rasmussen [EMAIL PROTECTED] writes:
Not sure about your position here. You claimed that it would be a good idea to
freeze the on disk format for at least a couple of versions.
I said it would be a good idea to freeze the format of user tables (and
indexes) across multiple
Joshua D. Drake [EMAIL PROTECTED] writes:
Fair enough. On another front then... would all this energy we are
talking about with pg_upgrade
be better spent on pg_dump/pg_dumpall/pg_restore?
Well, we need to work on pg_dump too. But I don't foresee it ever
getting fast enough to satisfy the
No can do, unless your intent is to force people to work on pg_upgrade
and nothing else (a position I for one would ignore ;-)). With such a
policy and no pg_upgrade we'd be unable to apply any catalog changes at
all, which would pretty much mean that 7.5 would look exactly like 7.4.
Not
Joshua D. Drake [EMAIL PROTECTED] writes:
The reality of pg_dump is not a good one. It is buggy and not very
reliable.
I think everyone acknowledges that we have more work to do on pg_dump.
But we have to do that work anyway. Spreading ourselves thinner by
creating a whole new batch of code
On Sat, 2003-09-20 at 11:17, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
No, I'm not suggesting no catalog changes ... wait, I might be wording
this wrong ... there are two changes that right now requires a
dump/reload, changes to the catalogs and changes to the data
On Thu, 2003-09-18 at 16:29, Andrew Sullivan wrote:
On Sat, Sep 13, 2003 at 10:52:45AM -0500, Ron Johnson wrote:
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
Marc G. Fournier [EMAIL PROTECTED] writes:
hmmm ... k, is it feasible to go a release or two at a time without on
disk changes? if so, pg_upgrade might not be as difficult to maintain,
since, unless someone an figure out a way of doing it, 'on disk change
releases' could still require
On Fri, 19 Sep 2003 18:51:00 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
transfer the schema into the new installation using pg_dump -s and
then push the user tables and indexes physically into place.
I'm more in favour of in-place upgrade. This might seem risky, but I
think we can expect users to
On Fri, 19 Sep 2003 20:06:39 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Perhaps you should go back and study what
pg_upgrade actually did.
Thanks for the friendly invitation. I did that.
It needed only minimal assumptions about the
format of either old or new catalogs. The reason is that it
On Fri, 19 Sep 2003, Tom Lane wrote:
I think we could definitely adopt a policy of on-disk changes not
oftener than every X releases if we had a working pg_upgrade, even
without doing any extra work to allow updates. People who didn't want
to wait for the next incompatible release could
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
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
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
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
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
Andrew Rawnsley wrote:
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
Using eRserver may help you work around the problem, given certain
conditions. It doesn't solve it. I think if we can get Mr.
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.
Joshua D. Drake [EMAIL PROTECTED] writes:
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.
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
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,
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
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 [EMAIL PROTECTED]:
And that has nothing to do with user need as a
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
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
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
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
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
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
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
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
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
Joshua D. Drake [EMAIL PROTECTED] 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
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
Joshua D. Drake [EMAIL PROTECTED] 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
Andrew Rawnsley [EMAIL PROTECTED] 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
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
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
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
Not that I know anything about the internal workings of PG but it seems like a
big part of the issue is the on disk representation of database. I've never had
a problem with the whole dump/restore process and in fact anyone that has been
doing this long enough will remember when that process was
Quoting Tom Lane [EMAIL PROTECTED]:
Network Administrator [EMAIL PROTECTED] writes:
The abstraction I am talking about would be a logical layer that would
handle
disk I/O including the format of that data (lets call this the ADH).
This sounds good in the abstract, but I don't see how you
Network Administrator [EMAIL PROTECTED] writes:
... However it seems to me that right now that this might not be
possible while the backend is changing between major releases.
Perhaps once that doesn't fluxate as much it might be feasible to
create these layer so that it is not too fat.
He is right, it might be a good idea to head this problem 'off at the
pass'. I am usually pretty good at predicting technilogical trends. I've
Well, the only solution I can see is to make an inline conversion tool that
knows about every step from earlier versions.
I believe this has been
Ron Johnson wrote:
On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:
Small soapbox moment here...
ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the
On Fri, 2003-09-12 at 17:48, Joshua D. Drake wrote:
Hello,
The initdb is not always a bad thing. In reality the idea of just
being able to upgrade is not a good thing. Just think about the
differences between 7.2.3 and 7.3.x... The most annoying (although
appropriate) one being that
Hi
Yes, it's been discussed to death, and it isn't easy. See the archives
That's what I thought.
interesting category. It is in the category of things that will only
happen if people pony up money to pay someone to do uninteresting work.
And for all the ranting, I've not seen any ponying.
On Fri, 12 Sep 2003, Ron Johnson wrote:
On Fri, 2003-09-12 at 17:48, Joshua D. Drake wrote:
Hello,
The initdb is not always a bad thing. In reality the idea of just
being able to upgrade is not a good thing. Just think about the
differences between 7.2.3 and 7.3.x... The most
On Sat, 13 Sep 2003, Ron Johnson wrote:
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
Kaare Rasmussen [EMAIL PROTECTED] writes:
interesting category. It is in the category of things that will only
happen if people pony up money to pay someone to do uninteresting work.
And for all the ranting, I've not seen any ponying.
Just for the record now that there's an argument that big
'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?
That's just what I was
On Sat, 2003-09-13 at 11:21, Marc G. Fournier wrote:
On Sat, 13 Sep 2003, Ron Johnson wrote:
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,
On Sat, 2003-09-13 at 10:10, Marc G. Fournier wrote:
On Fri, 12 Sep 2003, Ron Johnson wrote:
On Fri, 2003-09-12 at 17:48, Joshua D. Drake wrote:
Hello,
The initdb is not always a bad thing. In reality the idea of just
being able to upgrade is not a good thing. Just think about
Ron Johnson [EMAIL PROTECTED] writes:
And I strongly dispute the notion that it would only take 3 hours
to dump/restore a TB of data. This seems to point to a downside
of MVCC: this inability to to page-level database backups, which
allow for rapid restores, since all of the index structures
On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
[EMAIL PROTECTED] wrote:
Agreed, but if anyone has a table with close to 1600 columns in a
table...
This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so
Kaare Rasmussen [EMAIL PROTECTED] writes:
I believe this has been discussed before, but it does not seem to be a small
or an easy task to implement.
Yes, it's been discussed to death, and it isn't easy. See the archives
for Lamar Owen's eloquent rants on the subject, and various hackers'
On Fri, 12 Sep 2003, Ron Johnson wrote:
On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:
Small soapbox moment here...
ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes
On Fri, Sep 12, 2003 at 03:48:48PM -0700, Joshua D. Drake wrote:
The initdb is not always a bad thing. In reality the idea of just
being able to upgrade is not a good thing. Just think about the
differences between 7.2.3 and 7.3.x... The most annoying (although
appropriate) one being that
On Fri, 2003-09-12 at 17:01, Kaare Rasmussen wrote:
He is right, it might be a good idea to head this problem 'off at the
pass'. I am usually pretty good at predicting technilogical trends. I've
Well, the only solution I can see is to make an inline conversion tool that
knows about every
Hello,
The initdb is not always a bad thing. In reality the idea of just
being able to upgrade is not a good thing. Just think about the
differences between 7.2.3 and 7.3.x... The most annoying (although
appropriate) one being that integers can no longer be ''.
If we provide the ability to
MGF == Marc G Fournier [EMAIL PROTECTED] writes:
MGF Without a fair amount of testing, especially on other platforms, it most
MGF likely won't happen in the distribution itself ... one of the things that
MGF was bantered around for after v7.4 is released is seeing how increasing it
MGF on the
I haven't had a chance to sit down and do any exhaustive testing
yet and don't think I will for a while. That said, once 7.4 goes
gold, I'm going to provide databases/postgresql-devel with a
tunable that will allow people to choose what block size they
would like (4k, 8K, 16K, 32K, or
I haven't had a chance to sit down and do any exhaustive testing yet and
don't think I will for a while. That said, once 7.4 goes gold, I'm
going to provide databases/postgresql-devel with a tunable that will
allow people to choose what block size they would like (4k, 8K, 16K,
32K, or 64K)
AR == Andrew Rawnsley [EMAIL PROTECTED] writes:
AR Anyone out there using beta 2 in production situations? Comments on
AR stability? I am rolling out a project in the next 4 weeks, and really
AR don't want to go though an upgrade soon after its released on an
AR Unsuspecting Client, so I would
On Wed, 10 Sep 2003, Vivek Khera wrote:
AR == Andrew Rawnsley [EMAIL PROTECTED] writes:
AR Anyone out there using beta 2 in production situations? Comments on
AR stability? I am rolling out a project in the next 4 weeks, and really
AR don't want to go though an upgrade soon after its
76 matches
Mail list logo
