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.
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,
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 woul
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 g
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 buffe
--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
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,
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
>
$$$ -- 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
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 S
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
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 t
On Mon, 2003-09-22 at 18:30, Tom Lane wrote:
> "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. Bu
"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
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 multipl
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 pg_dump/pg_dumpa
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.
> >
> >
>
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 i
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 releases. T
> 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
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 dat
"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 c
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 cou
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 tha
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 user
On Fri, 19 Sep 2003 17:38:13 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>> A working pg_upgrade is *not* the first thing we need.
>
>Yes it is.
At the risk of being called a stubborn hairsplitter, I continue to say
that pg_upgrade is not the *first* thing we need. Maybe the second
...
> As you
"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 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 requis
"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 c
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
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.
Using eRserver may help you work around the problem, given certain
conditions. It doesn't solve it. I think if we can get Mr. Drak
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 muc
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 a
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
star
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
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 t
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.
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, cryi
I had already committed $50/mo.
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
Dennis Gearon <[EMAIL PROTECTED]> uttered something amazingly similar to:
Robert Creager wrote:
Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <[EMAIL PROTECTED]
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 cu
> Date: Tue, 16 Sep 2003 14:39:47 -0700
> From: "Joshua D. Drake" <[EMAIL PROTECTED]>
> To: Andrew Rawnsley <[EMAIL PROTECTED]>
> Cc: "Marc G. Fournier" <[EMAIL PROTECTED]>,
> PgSQL General ML <[EMAIL PROTECTED]>
> Subject: Re: State of Beta 2
> Message-ID: <[EMAIL PROTECTED]>
>
> >
> > Tying
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)
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
i
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 e
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
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 ti
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,
sinc
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
occasi
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 develope
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
> > 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
> > starte
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:5
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
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 c
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
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 wa
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.
>
>
On Sun, 2003-09-14 at 23:08, Tom Lane wrote:
> 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 feasibl
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.
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
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 g
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 s
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. J
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, shel
'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 think
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 argumen
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
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
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 pon
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
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 lists
> 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 dis
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
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
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
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
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'
f
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,
> 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 6
> > 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,
> "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
MG
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
> "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,
83 matches
Mail list logo
