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
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
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 gue
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 gue
day, September 14, 2003 10:20 AM
> To: Lamar Owen
> Cc: PgSQL General ML
> Subject: Re: need for in-place upgrades (was Re: [GENERAL] State of
>
>
>
> >At 07:16 PM 9/13/2003 -0400, Lamar Owen wrote:
> >'migration' server. And I really don't want t
-place upgrades (was Re: [GENERAL] State of
>At 07:16 PM 9/13/2003 -0400, Lamar Owen wrote:
>'migration' server. And I really don't want to think about
dump/restore
>of 100TB (if PostgreSQL actually stores the image files, which it
might).
Hmm. Just curious, do people g
El Dom 14 Sep 2003 12:20, Lincoln Yeoh escribió:
> >At 07:16 PM 9/13/2003 -0400, Lamar Owen wrote:
> >'migration' server. And I really don't want to think about dump/restore
> >of 100TB (if PostgreSQL actually stores the image files, which it might).
>
> Hmm. Just curious, do people generally back
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
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
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
14 matches
Mail list logo
