Balkrishna Sharma wrote:
>> average about two drive failures a month
> You must be having a real huge postgres setup with several hundreds
> of drives to have such high frequency of failure.
About 100 database servers with over 1000 drives spinning 24/7. Also
probably significant, managemen
.@wicourts.gov
> To: b...@hotmail.com; pgsql-admin@postgresql.org; q...@vp.pl
> Subject: Re: [ADMIN] db recovery after raid5 failure
>
> Balkrishna Sharma wrote:
>
> > If the database is not extremely huge, makes you wonder what does
> > a RAID actually give us.
>
Balkrishna Sharma wrote:
> If the database is not extremely huge, makes you wonder what does
> a RAID actually give us.
Well, RAID5 gives you a situations where you must have a second
drive fail before recovery for the first failure is complete, versus
being instantly dead on a single-drive fa
can't do
anything about.
> Date: Mon, 21 Jun 2010 15:30:45 -0500
> From: kevin.gritt...@wicourts.gov
> To: pgsql-admin@postgresql.org; q...@vp.pl
> Subject: Re: [ADMIN] db recovery after raid5 failure
>
> wrote:
>
> > I have serious problems recovering our db
wrote:
> I have serious problems recovering our db after recent raid5
> failure. Long story short - no recent dumps, some missing files
> (like pg_control).
Been there -- at least on the end of helping with recovery for
people in that position with a different database product. It can
be ver
Hello
I have serious problems recovering our db after recent raid5 failure.
Long story short - no recent dumps, some missing files (like pg_control).
long version of the story:
our raid failed.. badly. I was able to recover most of the files but some
(like pg_control) are missing (possibly more,
On Fri, Feb 26, 2010 at 7:41 PM, Tom Lane wrote:
> Roland Wells writes:
>> On new hardware, installed pg8.1 and restored data directory and
>> attempted to start pg. After fixing some config differences, it
>> complained of a missing pg_clog/xxx file. After searching the archives
>> for hints, ad
Roland Wells writes:
> On new hardware, installed pg8.1 and restored data directory and
> attempted to start pg. After fixing some config differences, it
> complained of a missing pg_clog/xxx file. After searching the archives
> for hints, added a file of zero's and pg starts successfully. The db
Hello all,
Background:
DB resides on a mirrored array, HD1 goes bad and before it can be
replaced, HD2 starts throwing hardware errors. We were able to get a
DD from HD2 and have restored the box quite successfully with the
exception of the pg db. There WAS corruption to the filesystem. Since
the
Hi Dominique,
>ERROR: literal carriage return found in data
>HINT: Use "\r" to represent carriage return.
>CONTEXT: COPY netjuke_tracks, line 3312: "3196 940 335 4
>21 Things I Want In A Lover 4991999
>207 1 20022003-05-16 21:24:08+02 192 44100
>MPEG ..."
>
>"phpbb_po
On Mon, 2003-12-01 at 09:35, Dominique Fenenr wrote:
> Hi all,
>
> I recently upgraded postgresql from 7.1 to 7.4. I did a
>
> pg_dumpall > backup
>
> then installed the new version and tried to recover my data with
>
> psql template1
> But something went wrong. The log shows the following:
Hi all,
I recently upgraded postgresql from 7.1 to 7.4. I did a
pg_dumpall > backup
then installed the new version and tried to recover my data with
psql template1
Just to make sure - given that there is plenty of space available (database is
slightly larger than 1GB and there is almost 10GB free), there should be no
problem with vacuum?
Or should I upgrade regardless? (I generally like to keep stable system
stable, unless I know there is a specific reason
DBVer: 6.5.0, downloaded on 5/25/99
Linux: 2.0.35
Compaq 450MHz PentiumII with 256MB RAM and 1GB swap
I think I may have dug myself a deep hole. But hopefully someone
can help me climb out.
I was vacuuming my database, with analyze on; the vacuum was killed,
and I found I could no longer access
14 matches
Mail list logo
