ked just before writing a block and just after reading it? I know this
would degrade performance, but I think we can afford that. Would it be possible to incorporate such code without having
to do too much patching?
Thanks in advance
Alexandra Nitzschke
Thomas Goerner
Tom Lane schrieb:
Alexan
Yes, of course.
After we started up the copied database, the system runs withour error for two
days.
That means some recordsets has been inserted sucessfully already.
Gregory Stark schrieb:
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
This monday I updated postgres to 8.3.5
Yes, its a btree.
Tom Lane schrieb:
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
We have had a look at the /var/log files, no system crash, kernel panic or
messages like this has happened.
What this smells like is a failed page split --- somewhere in the index
there is a dow
evening runs "vacuum analyze".
Regards,
A. Nitzschke
Craig Ringer schrieb:
Alexandra Nitzschke wrote:
Hi,
we have had similar postgres problems in the past.
Please have a look at Bug 3484.
We didn't resolve the problems metioned in bug 3484. The other postgres
developers als
10.0
Kernel 2.6.22.6-smp
Intel-Mainboard + 2x Intel XEON 2,80 GHz 2MB FSB800
4x 1024MB ECC Registered DDR2 RAM
3Ware Raid Controller 9500S-4
Regards,
A. Nitzschke
Craig Ringer schrieb:
Alexandra Nitzschke wrote:
Hi,
we encountered the following error while inserting a record into a
Hi,
we encountered the following error while inserting a record into a table:
org.postgresql.util.PSQLException: ERROR: could not read block 77 of relation 1663/16385/388818775: read only 0 of 8192
bytes
Using postgres 8.3.5
The reported object is an index.
The size of its data file is 63078
Hi,
since our last report at 15.02.2008 we again encountered database errors:
Livesystem:
30.04.2008 ERROR: invalid page header in block 12324 of relation "tzf_taf_fk"
--
- 12.09.2008 Update postgres from 8.1.3 to 8.3.3.
--
We did some analyzing and found out some mysterious things.
First we used the pg_check tool to analyze the table.
The result is:
# select pgcheck_page( 211593798 );
WARNING: relation 'adresse_080103', tuple (46,11): start of tuple is not
aligned properly
WARNING: relation 'adresse_080103', tu
Hi,
we retrieved again a database error:
pg_dump: Error message from server: ERROR: could not access status of
transaction 2926020847
DETAIL: Could not open file "pg_clog/0AE6": Datei oder Verzeichnis nicht
gefunden.
pg_dump: The command was: COPY public.adresse_080103 (id, adr_id, adt_id,
