cb wrote:
My understanding is, before I joined the company, they did an upgrade
from 7 on Linux to 8 on Windows and got bit by some change in PG that
broke a bunch of code. After that, they have just refused to budge
from the 8.0.4 version we are on and know the code works against.
Yes; that's
cb c...@mythtech.net wrote:
On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
Make sure you're not in the line of fire when (not if) that version
eats your data. Particularly on Windows, insisting on not
upgrading that version is unbelievably, irresponsibly stupid.
There are a *large* number of
On Tue, Nov 17, 2009 at 7:59 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
cb c...@mythtech.net wrote:
On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
Make sure you're not in the line of fire when (not if) that version
eats your data. Particularly on Windows, insisting on not
upgrading
Greg Smith wrote:
cb wrote:
My understanding is, before I joined the company, they did an upgrade
from 7 on Linux to 8 on Windows and got bit by some change in PG that
broke a bunch of code. After that, they have just refused to budge
from the 8.0.4 version we are on and know the code works
On Mon, 2009-11-16 at 23:57 -0500, cb wrote:
On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
Myself and the other guy responsible for the underlying hardware have
already gone down this route. The big bosses know our stance and know
it isn't us preventing the upgrade. After that, there isn't
I've got a pair of servers running PostgreSQL 8.0.4 on Windows. We
have several tables that add and delete massive amounts of data in a
single day and are increasingly having a problem with drive
fragmentation and it appears to be giving us a decent performance hit.
This is external
On Mon, Nov 16, 2009 at 12:14 PM, cb c...@mythtech.net wrote:
I've got a pair of servers running PostgreSQL 8.0.4 on Windows. We have
several tables that add and delete massive amounts of data in a single day
and are increasingly having a problem with drive fragmentation and it
appears to be
cb wrote:
I'm curious if anyone else has used Diskeeper's Automatic Mode in
combination with PostgreSQL to defrag and keep the drive defragged
while PostgreSQL is actually running.
Thanks!
-chris
www.mythtech.net
I've been a Diskeeper customer for about 10 years now and consider it
On Mon, Nov 16, 2009 at 1:11 PM, Robert Schnabel schnab...@missouri.edu wrote:
cb wrote:
I'm curious if anyone else has used Diskeeper's Automatic Mode in
combination with PostgreSQL to defrag and keep the drive defragged while
PostgreSQL is actually running.
Thanks!
-chris
So the short answer is yes, I have it running with
PostgreSQL and have not had any problems.
Have you unplugged the power cord a few times in the middle of heavy
write activity?
...Robert
Nope. Forgive my ignorance but isn't that what a UPS is for anyway?
Along with a BBU
On Mon, Nov 16, 2009 at 1:04 PM, Robert Schnabel schnab...@missouri.edu wrote:
So the short answer is yes, I have it running with
PostgreSQL and have not had any problems.
Have you unplugged the power cord a few times in the middle of heavy
write activity?
...Robert
Nope. Forgive my
On Mon, Nov 16, 2009 at 1:12 PM, Scott Marlowe scott.marl...@gmail.com wrote:
Power supplies / UPSes fail far more often than one might think. And
a db that doesn't come back up afterwards is not to be placed into
production.
Note that there are uses for databases that can lose everything and
Robert Schnabel wrote:
Nope. Forgive my ignorance but isn't that what a UPS is for anyway?
Along with a BBU controller.
If you have a UPS *and* a BBU controller, then things are much
better--those should have a write cache that insulates you from the
worst of the problems. But just a UPS
Greg Smith wrote:
Robert Schnabel wrote:
Nope. Forgive my ignorance but isn't that what a UPS is for anyway?
Along with a BBU controller.
If you have a UPS *and* a BBU controller, then things are much
better--those should have a write cache that insulates you from the
worst of the
My reply about server failure was shwoing what could go wrong at the server
level assuming a first-class, properly run data center, with fully redundant
power, including a server with dual power supplies on separate cords fed by
separate UPS'es etc.
Unfortunately, *correctly* configured A/B
Scott Marlowe wrote:
On Mon, Nov 16, 2009 at 1:04 PM, Robert Schnabel schnab...@missouri.edu wrote:
So the short answer is yes, I have it running with
PostgreSQL and have not had any problems.
Have you unplugged the power cord a few times in the middle of heavy
write activity?
Dave Crooke wrote:
My reply about server failure was shwoing what could go wrong at the
server level assuming a first-class, properly run data center, with
fully redundant power, including a server with dual power supplies on
separate cords fed by separate UPS'es etc.
Never had a
On Mon, Nov 16, 2009 at 1:32 PM, Robert Schnabel schnab...@missouri.edu wrote:
Ok, so you have sufficiently sparked my curiosity as to whether Diskeeper
will in any way cause Postgres to fail the power chord test. Unfortunately
I have some deadlines to meet so won't be able to test this out
On Mon, Nov 16, 2009 at 1:32 PM, Karl Denninger k...@denninger.net wrote:
Dave Crooke wrote:
My reply about server failure was shwoing what could go wrong at the
server level assuming a first-class, properly run data center, with
fully redundant power, including a server with dual power
Scott Marlowe wrote:
On Mon, Nov 16, 2009 at 1:32 PM, Robert Schnabel schnab...@missouri.edu wrote:
Ok, so you have sufficiently sparked my curiosity as to whether Diskeeper
will in any way cause Postgres to fail the power chord test. Unfortunately
I have some deadlines to meet so
I also have backup software running that does
complete drive imaging so I should be able to do this fairly safely.
Here is the plan...
1) Shut down the Diskeeper service, run a query that is write heavy and
then pull the chord on the box. Wait a few minutes then plug it back in
and see if
Craig James escribió:
Do it more than once. This is a highly erratic test that can catch
your system at a wide variety of points, some of which cause no
problems, and some of which can be catastrophic. If you test and it
fails, you know you have a problem. If you test and it doesn't fail,
On Mon, Nov 16, 2009 at 03:20:12PM -0500, Greg Smith wrote:
Robert Schnabel wrote:
Nope. Forgive my ignorance but isn't that what a UPS is for anyway?
Along with a BBU controller.
If you have a UPS *and* a BBU controller, then things are much
better--those should have a write cache that
On Mon, Nov 16, 2009 at 2:04 PM, Robert Schnabel schnab...@missouri.edu wrote:
Granted, but the point of me testing this is to say whether or not the
Diskeeper service could introduce a problem. If the system recovers without
Diskeeper running but does not recover while Diskeeper is actively
On Nov 16, 2009, at 1:09 PM, Robert Haas wrote:
I'm not sure what the answer is to your actual question, but I'd
highly recommend upgrading to 8.3 or 8.4. The performance is likely
to be a lot better, and 8.0/8.1 are no longer supported on Windows.
Ugh, yeah, I'd love to upgrade but the
On Nov 16, 2009, at 1:11 PM, Robert Schnabel wrote:
I've been a Diskeeper customer for about 10 years now and consider
it 'must have' software for Windows machines.
snip
So the short answer is yes, I have it running with PostgreSQL and
have not had any problems.
So that seems to be a
cb c...@mythtech.net writes:
Ugh, yeah, I'd love to upgrade but the powers that get to make that
decision have no interest in upgrading. So I'm stuck on 8.0.4,
Make sure you're not in the line of fire when (not if) that version
eats your data. Particularly on Windows, insisting on not
Tom Lane wrote:
cb c...@mythtech.net writes:
Ugh, yeah, I'd love to upgrade but the powers that get to make that
decision have no interest in upgrading. So I'm stuck on 8.0.4,
Make sure you're not in the line of fire when (not if) that version
eats your data. Particularly on
On Mon, Nov 16, 2009 at 7:45 PM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
cb c...@mythtech.net writes:
Ugh, yeah, I'd love to upgrade but the powers that get to make that
decision have no interest in upgrading. So I'm stuck on 8.0.4,
Make sure you're not in the line of fire
On Nov 16, 2009, at 8:31 PM, Tom Lane wrote:
Make sure you're not in the line of fire when (not if) that version
eats your data. Particularly on Windows, insisting on not upgrading
that version is unbelievably, irresponsibly stupid. There are a
*large* number of known bugs.
I hear ya, and
30 matches
Mail list logo
