On Jun 26, 2008, at 5:41 AM, Rodrigo Gonzalez wrote:
> Tom Lane wrote:
>> Rodrigo Gonzalez <rjgonzale@gmail.com> writes:
>>> Craig Ringer wrote:
>>>> What platform are you using?
>>
>>> It's running under CentOS 4.4 using ext3, no RAID or LVM.
>>> Server is quad xeon 64 bits 3 GHz
>>
>> Ugh, I'd have liked to think RHEL4/Centos4 would be more reliable
>> than
>> that :-(. Still, you might have an issue with trying to use hardware
>> that's not supported by RHEL4, especially if it's not a very recent
>> version of RHEL4. Did you check compatibility charts before
>> purchasing?
>> https://hardware.redhat.com/
>>
>> regards, tom lane
>
> It had been working with pgsql 8.1 and 8.2 for 2 years without
> problems.
> Suspicious is that problems started next day I've upgraded to 8.3.
>
> I've tried reinstalling 8.3 from scratch and again, next morning, oid
> 2836 is missing...
Ok, throwing a few "random" questions in your direction:
What procedure did you use to do those upgrades? Maybe something went
wrong there? I'm assuming you upgraded using dump/restore, or
postgres would have complained about the version of the data files at
startup, but maybe you did something unusual.
Are you sure there's only one version of postgres running?
Are all your libraries up to date, no old versions hanging around
where they should have been replaced?
Do you have any stored procedures in C? If so, do you perhaps use
malloc/free instead of the ones Postgres provides (reasoning you may
be freeing a reference to the toast table somehow)?
Is that data-file on a mirror where one part of the mirror may be
mirroring a bad sector over the good one on the other drive(s)?
I may be talking nonsense, I'm no Tom Lane, but I know a fair share
about postgres ;)
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4863ce3b243481261463208!
