On Tue, 2010-03-09 at 15:43 -0600, Kenneth Marshall wrote:
> On Tue, Mar 09, 2010 at 01:28:20PM -0800, Joshua D. Drake wrote:
> > On Tue, 2010-03-09 at 14:25 -0700, Scott Marlowe wrote:
> > > On Tue, Mar 9, 2010 at 2:06 PM, Joshua D. Drake
> > > wrote:
> > > > On Tue, 2010-03-09 at 13:35 -0700, S
On Tue, Mar 09, 2010 at 01:28:20PM -0800, Joshua D. Drake wrote:
> On Tue, 2010-03-09 at 14:25 -0700, Scott Marlowe wrote:
> > On Tue, Mar 9, 2010 at 2:06 PM, Joshua D. Drake
> > wrote:
> > > On Tue, 2010-03-09 at 13:35 -0700, Scott Marlowe wrote:
> > >
> > >> > In a nutshell, I am heartly recomm
On Tue, 2010-03-09 at 14:25 -0700, Scott Marlowe wrote:
> On Tue, Mar 9, 2010 at 2:06 PM, Joshua D. Drake
> wrote:
> > On Tue, 2010-03-09 at 13:35 -0700, Scott Marlowe wrote:
> >
> >> > In a nutshell, I am heartly recommending virtualization.
> >>
> >> In a nutshell, you are relying on luck that
On Tue, Mar 9, 2010 at 2:06 PM, Joshua D. Drake wrote:
> On Tue, 2010-03-09 at 13:35 -0700, Scott Marlowe wrote:
>
>> > In a nutshell, I am heartly recommending virtualization.
>>
>> In a nutshell, you are relying on luck that both heavy iron machines
>> can't lose power at the same time. Sure, i
On Tue, 2010-03-09 at 13:35 -0700, Scott Marlowe wrote:
> > In a nutshell, I am heartly recommending virtualization.
>
> In a nutshell, you are relying on luck that both heavy iron machines
> can't lose power at the same time. Sure, it's a low possibility, but
> it's still a real one.
>
Not lu
And Jan-Ivar, please don't think I'm saying your way is not a valid
way to do things, it just requires things like read recoverable dbs
via PITR or something like that. Without a read to recover separate
machine for your big db you could be facing downtime measured in hours
or even days.
--
Sent
On Tue, Mar 9, 2010 at 1:18 PM, Jan-Ivar Mellingen
wrote:
> Regarding 'pulling the plug' on the servers: Physical or virtual, always use
> a UPS. You can pull the plug as much as you like. When the power is about to
> run out it signals the server, which shuts down cleanly.
> Our servers have dual
Tom Lane skrev:
But a virtualization layer can kill your performance and/or
reliability. Ask hard questions about why that decision is being
imposed on you and what benefits it will have.
I have been following this discussion, and I feel I have to make a comment.
Our company has moved a
On Tue, Mar 9, 2010 at 7:34 AM, Kenneth Marshall wrote:
> Hi Ben,
>
> If you must use a VMware server for your databases, please run
> some "pull-the-power-plug" tests on your system to ensure that
> your data integrity is maintained. Virtual machines can sometimes
> cache filesystem updates in th
Hi Ben,
If you must use a VMware server for your databases, please run
some "pull-the-power-plug" tests on your system to ensure that
your data integrity is maintained. Virtual machines can sometimes
cache filesystem updates in the name of performance with disasterous
consequences to your filesyst
Thanks all.
I cannot change the decision on vmware or layout, but it's great to know
that the rpm way is a valid one.
I appreciate all inputs.
Regards,
Ben Kim
On Mon, 8 Mar 2010, Scott Marlowe wrote:
On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
Dear list,
I have about 20 postgr
Scott Marlowe wrote:
On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
I have someone who opposes the use of standard rpms (even yums) for this
reason. I thought I'd check out how it is received professionally.
Sounds like a religious argument. I mostly used packages, unless I
can't. (i.e. tw
Plugge, Joe R. wrote:
It has been a while ago Scott, I don't remember exactly. If it currently is
not an issue then I will not be so resistant to using packages/rpms for
postgres installs. One other item, and maybe it is just that I have never done
it ... how would one install a package/rpm
On Fri, 2010-03-05 at 17:39 -0500, John A. Sullivan III wrote:
> On Fri, 2010-03-05 at 14:13 -0800, Bob Lunney wrote:
> >
> > --- On Fri, 3/5/10, John A. Sullivan III
> > wrote:
> >
> > > From: John A. Sullivan III
> > > Subject: [ADMIN] Querying the same column and table across schemas
> > >
14 matches
Mail list logo
