More details on Database corruption

It seems to be the same for me...
But I can see "tasks" table after restarting of psql,
so it doesn't crash the data files.

What can be usefull is the messages in the server.log file:
Too Large Allocation Request ... File: mcxt.c Line: 232

I don't know the code of PG, but we can ask PG "gurus" ...
Dimitri

On Thu, 13 Aug 1998, you wrote:

Hi,

I managed to recreate a simple example that's crashing postgres. I am
running on a DEC Alpha with Digital Unix Version 4.0d and Postgres
3.2. I tried this example several times, on several databases and it
crashes every time. We also re-built Postgres and still did not work.
Here's the example. Can anybody please help?

Thank you...
George K.
/***** INPUT FILE: hist.sql *******/

drop table tasks;
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);

INSERT INTO tasks (task, job) VALUES (1, 1);
select * from tasks;
update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
select * from tasks;

/****** OUTPUT FROM pgsql **********/
test=> \i hist.sql
drop table tasks;
DROP
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);
CREATE

INSERT INTO tasks (task, job) VALUES (1, 1);
INSERT 4410388 1
select * from tasks;
task|job|version1|version2|version3|version4|version5
----+---+--------+--------+--------+--------+--------
1| 1| | | | |
(1 row)

update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
UPDATE 1
select * from tasks;
FATAL: unrecognized data from the backend. It probably dumped core.
FATAL: unrecognized data from the backend. It probably dumped core.

EOF
test=>

--
=====================================================
Dimitri KRAVTCHUK (dim) Sun Microsystems
Benchmark Engineer France
dimitri@France.Sun.COM
=====================================================

On Thu, 13 Aug 1998, George Kousi wrote:

CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);

A zero-length string ('') is not a valid default value for a CHAR(6).
I replaced it with ' ' (six blanks) and all runs fine.

I run 6.3.1 on Linux 2.0.27 and your script fails on the first insert
without corruption problems. I don't know why it only fails on update on
your system.

Regards - guido

------------------------------------------------------------------------
// Guido Carlo Piazzi Accompagnatore naturalistico
// gpiazzi@nemo.it Visitate il sito WWW.ParcoDelTicino.Pmn.It
------------------------------------------------------------------------

I am able to reproduce this. The problem is that the DEFAULT string is
not the same length as the column. Anyone know how to fix this?

Hi,

I managed to recreate a simple example that's crashing postgres. I am
running on a DEC Alpha with Digital Unix Version 4.0d and Postgres
3.2. I tried this example several times, on several databases and it
crashes every time. We also re-built Postgres and still did not work.
Here's the example. Can anybody please help?

Thank you...
George K.
/***** INPUT FILE: hist.sql *******/

drop table tasks;
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);

INSERT INTO tasks (task, job) VALUES (1, 1);
select * from tasks;
update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
select * from tasks;

/****** OUTPUT FROM pgsql **********/
test=> \i hist.sql
drop table tasks;
DROP
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);
CREATE

INSERT INTO tasks (task, job) VALUES (1, 1);
INSERT 4410388 1
select * from tasks;
task|job|version1|version2|version3|version4|version5
----+---+--------+--------+--------+--------+--------
1| 1| | | | |
(1 row)

update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
UPDATE 1
select * from tasks;
FATAL: unrecognized data from the backend. It probably dumped core.
FATAL: unrecognized data from the backend. It probably dumped core.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

The problem is that the DEFAULT string is
not the same length as the column. Anyone know how to fix this?

I can put this on my list of things to look at, but I'm not sure why
this is causing the backend to crash. Is is a problem with storage
allocation when updating columns? Or is it a problem with storage which
is already corrupted by the zero-length default character strings?? I
would think that the default string is not looked at during the update,
so the damage happened during the initial insert, right?

- Tom

The problem is that the DEFAULT string is
not the same length as the column. Anyone know how to fix this?

I can put this on my list of things to look at, but I'm not sure why
this is causing the backend to crash. Is is a problem with storage
allocation when updating columns? Or is it a problem with storage which
is already corrupted by the zero-length default character strings?? I
would think that the default string is not looked at during the update,
so the damage happened during the initial insert, right?

It is an Assert which is saying, 'If it is a fixed-length field, it
better have the same length.'

Do you want the backtrace line?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Do you want the backtrace line?

Just tell me where the check is happening, and I'll look. Not sure what
to do about it yet...

- Tom

Here is a bug report from August. The bug still exists.

If you remove the DEFAULT's, it does not crash. If you exit the session
after the UPDATE, and execute SELECT in a new session, it does not crash
and yields the correct results.

The crash happens in the executor, and it clearly shows it getting an
invalid value for the version2 column:

(gdb) print att[3][0]
$12 = {attrelid = 0, attname = {data = "version2", '\000' <repeats 23 times>},
atttypid = 1042, attdisbursion = 0, attlen = -1, attnum = 4, attnelems = 0,
attcacheoff = -1, atttypmod = 10, attbyval = 0 '\000', attisset = 0 '\000',
attalign = 105 'i', attnotnull = 0 '\000', atthasdef = 0 '\000'}
(gdb) print *(struct varlena *)value[3]
$13 = {vl_len = 538976305, vl_dat = " "}

Can anyone suggest a cause?

Hi,

I managed to recreate a simple example that's crashing postgres. I am
running on a DEC Alpha with Digital Unix Version 4.0d and Postgres
3.2. I tried this example several times, on several databases and it
crashes every time. We also re-built Postgres and still did not work.
Here's the example. Can anybody please help?

Thank you...
George K.
/***** INPUT FILE: hist.sql *******/

drop table tasks;
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);

INSERT INTO tasks (task, job) VALUES (1, 1);
select * from tasks;
update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
select * from tasks;

/****** OUTPUT FROM pgsql **********/
test=> \i hist.sql
drop table tasks;
DROP
CREATE TABLE tasks (
task INT4 NOT NULL,
job INT4 NOT NULL,
Version1 CHAR(6) DEFAULT '',
Version2 CHAR(6) DEFAULT '',
Version3 CHAR(6) DEFAULT '',
Version4 CHAR(6) DEFAULT '',
Version5 CHAR(6) DEFAULT ''
);
CREATE

INSERT INTO tasks (task, job) VALUES (1, 1);
INSERT 4410388 1
select * from tasks;
task|job|version1|version2|version3|version4|version5
----+---+--------+--------+--------+--------+--------
1| 1| | | | |
(1 row)

update tasks set version1='1',version2='2', version3='3', version4='4',
version5='5' where task=1;
UPDATE 1
select * from tasks;
FATAL: unrecognized data from the backend. It probably dumped core.
FATAL: unrecognized data from the backend. It probably dumped core.

EOF
test=>

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026