On Mon, 3 Nov 2003, Tom Lane wrote:
> Martin Edlman <edlman@fortech.cz> writes:
> > [ unstable index behavior ]
>
> I'm wondering about hardware problems --- how sure are you that you
> don't have flaky RAM or a bad disk drive?
I'll check this, the RAID controller reports this. RAM should be OK. I had
the same problem on the old (same type) server. We installed new server
(HW) with some BIOS upgrades and maintance utils and put the disks from
the old server to the new one.
I'll try to install PgSQL on some ordinary HW and test it.
> Also, what locale settings are you using in the database (use
> pg_controldata to verify this)? It seems possible that a broken
> locale definition could mess up indexes.
I use cs_CZ locale. But any of indexes we are talking about doesn't use
czech chars, furthermore even any of these tables doesn't contain czech
chars.
$ pg_controldata /var/lib/pgsql/data
pg_control version number: 72
Catalog version number: 200211021
Database cluster state: in production
pg_control last modified:
Current log file ID: 37
Next log file segment: 116
Latest checkpoint location: 25/732BA740
Prior checkpoint location: 25/732B04F8
Latest checkpoint's REDO location: 25/732BA740
Latest checkpoint's UNDO location: 0/0
Latest checkpoint's StartUpID: 44
Latest checkpoint's NextXID: 83236896
Latest checkpoint's NextOID: 30054204
Time of latest checkpoint:
Database block size: 8192
Blocks per segment of large relation: 131072
Maximum length of identifiers: 64
Maximum number of function arguments: 32
Date/time type storage: Floating point
Maximum length of locale name: 128
LC_COLLATE: cs_CZ.ISO8859-2
LC_CTYPE: cs_CZ.ISO8859-2
> I know the above sounds like passing the buck, but when you're the only
> one reporting such troubles, I have to ask what's different about your
> installation ...
I understand. I suppose that if my problem is somehow general you would
already know about it.
Regards,
--
Martin Edlman
Fortech s.r.o, Litomysl
Public PGP key: http://edas.visaci.cz/#keys
