Row data corruption under 7.3.5

Поиск
Список
Период
Сортировка
От Marc Mitchell
Тема Row data corruption under 7.3.5
Дата
Msg-id 004101c3ffbb$ebce29f0$7201050a@MarcM8500
обсуждение исходный текст
Ответ на Re: Commercial PostgreSQL support  (Devrim GUNDUZ <devrim@gunduz.org>)
Ответы Re: Row data corruption under 7.3.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
We are running a highly transaction-intensive application in the
following environment:

Postgres Version 7.3.5 built off the source tree, not RPMs
Operating System: Red Hat Enterprise Linux AS (v 2.1)
Kernel: 2.4.9-e.34smp
Hardware: Dell PE 2600-Dual 2.8 Ghz Xeon w/2GB RAM and Dual 36GB Mirrors
using PERC RAID

The same problem has occurred on at least three separate occasions on 3
different tables and manifests itself through the following error while
performing "COPY TABLE" commands:

ERROR:  MemoryContextAlloc: invalid request size 4294967293 lost
synchronization with server, resetting connection

In each case, by examining the copy table output up to the point where
it errors out, a single row could be identified that contained corrupted
char/varchar values but could be queried using primary key or numeric
lookups.  We've been able to work around the issue by deleting the row
and manually re-inserting it based on values determined from a previous
backup.  Note that in each case, it has been determined that the corrupt
row existed without a problem earlier as it could be found in old
backups.  Thus the rows seem to get into the table ok but got wacked at
some future point in time.

Any ideas on what's causing this?

Marc Mitchell - Senior Application Architect
Enterprise Information Solutions, Inc.
Downers Grove, IL 60515
marcm@eisolution.com



В списке pgsql-admin по дате отправления:

Предыдущее
От: Devrim GUNDUZ
Дата:
Сообщение: Re: Commercial PostgreSQL support
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PostgreSQL and phppgadmin woody backports