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=>





Thu, 13 Aug 1998 18:54:16 +0300
George Kousi <g.kousi@albourne.com>
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
=====================================================

Thu, 13 Aug 1998 18:45:01 +0200
Dimitri <dimitri@France.Sun.COM>
Re: [GENERAL] More details on Database corruption
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
------------------------------------------------------------------------


Fri, 14 Aug 1998 11:36:57 +0200 (MET DST)
Guido Piazzi <gpiazzi@nemo.it>
Re: [GENERAL] More details on Database corruption
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)

Sat, 22 Aug 1998 08:29:45 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] More details on Database corruption
> 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

Mon, 24 Aug 1998 15:01:39 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [GENERAL] More details on Database corruption
> > 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)

Mon, 24 Aug 1998 11:38:03 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] More details on Database corruption
> 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

Tue, 25 Aug 1998 02:57:17 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [GENERAL] More details on Database corruption
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

Sun, 14 Mar 1999 16:21:09 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] More details on Database corruption