On 10/06/2011 02:15 PM, Leif Biberg Kristensen wrote:
Model Family: Seagate Barracuda 7200.11 family
Device Model: ST31000340AS
Serial Number:9QJ1ZMHY
Firmware Version: SD15
Oh, joy. I have some of those, and can confirm their data-eating powers.
Thankfully mine were in a backup s
On Thursday 6. October 2011 07.07.11 Craig Ringer wrote:
> On 10/06/2011 03:06 AM, Leif Biberg Kristensen wrote:
> > I seemingly fixed the problem by stopping postgres and doing:
> >
> > balapapa 612249 # mv 11658 11658.old
> > balapapa 612249 # mv 11658.old 11658
> >
> > And the backup magically
On 10/06/2011 03:06 AM, Leif Biberg Kristensen wrote:
I seemingly fixed the problem by stopping postgres and doing:
balapapa 612249 # mv 11658 11658.old
balapapa 612249 # mv 11658.old 11658
And the backup magically works.
Woo! That's ... "interesting".
I'd be inclined to suspect filesyst
On 10/05/2011 03:43 PM, Leif Biberg Kristensen wrote:
On Thursday 6. October 2011 00.17.38 Steve Crawford wrote:
I'm thinking perhaps a funky memory problem - you are having odd crashes
after all.
I've been thinking about the memory myself, but it passes memtest86plus with
flying colors. Or at
On Thursday 6. October 2011 00.17.38 Steve Crawford wrote:
> I'm thinking perhaps a funky memory problem - you are having odd crashes
> after all.
I've been thinking about the memory myself, but it passes memtest86plus with
flying colors. Or at least it did the last time I checked which is a few
On 10/05/2011 02:48 PM, Leif Biberg Kristensen wrote:
I had a hang on the machine a few hours earlier that required a power-off
reboot. That has been a problem with this rig since I built it about a year
ago, it's probably a funky connection somewhere. This may be the direct cause
of the I/O err
On Wednesday 5. October 2011 22.41.49 Tom Lane wrote:
> Leif Biberg Kristensen writes:
> > I'm gonna move the data to another disk right now.
>
> Good plan.
Couple of things I forgot to mention, in case it matters:
The disk is a 1 TB Seagate Barracuda S-ATA, and it has been in use for about a
Leif Biberg Kristensen writes:
> I seemingly fixed the problem by stopping postgres and doing:
> balapapa 612249 # mv 11658 11658.old
> balapapa 612249 # mv 11658.old 11658
> And the backup magically works.
Wow, that is magic. I was going to suggest copying pg_opfamily from
template0, which wou
I seemingly fixed the problem by stopping postgres and doing:
balapapa 612249 # mv 11658 11658.old
balapapa 612249 # mv 11658.old 11658
And the backup magically works.
I'm gonna move the data to another disk right now.
regards, Leif
--
Sent via pgsql-general mailing list (pgsql-general@postgr
On Wednesday 5. October 2011 20.42.00 Tom Lane wrote:
> Postgres can't magically resurrect data that your drive lost, if that's
> what you were hoping for. However, you might be in luck, because that
> file is probably just an index and not original data. Try this:
>
> select relname from
Leif Biberg Kristensen writes:
> Running postgresql 9.0.5 on
> balapapa ~ # uname -a
> Linux balapapa 2.6.39-gentoo-r3 #1 SMP Sun Jul 17 11:22:15 CEST 2011 x86_64
> Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz GenuineIntel GNU/Linux
> I'm trying to run pg_dump on my database, and get an error:
> pg_
Running postgresql 9.0.5 on
balapapa ~ # uname -a
Linux balapapa 2.6.39-gentoo-r3 #1 SMP Sun Jul 17 11:22:15 CEST 2011 x86_64
Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz GenuineIntel GNU/Linux
I'm trying to run pg_dump on my database, and get an error:
pg_dump: SQL command failed
pg_dump: Error mes
12 matches
Mail list logo
