dbTalk Databases Forums  

Re: [BUGS] Bug related to out of memory condition (more information)

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss Re: [BUGS] Bug related to out of memory condition (more information) in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Jeff Davis
 
Posts: n/a

Default Re: [BUGS] Bug related to out of memory condition (more information) - 10-24-2006 , 05:33 PM






I have made a clearer example of the bug I reported to -hackers
yesterday:

http://archives.postgresql.org/pgsql...0/msg01252.php

The following example shows a simple case that fails on 8.0+ (including
CVS HEAD), but works fine on 7.4. There are two almost identical
situations, and one causes an ERROR and the other a PANIC. The only
difference is the column type: INT versus TEXT, respectively.

I am on FreeBSD. An OOM condition must be caused to see this bug. In
7.4, an OOM condition is not even caused for the query, so perhaps it
has a the same bug, but handles foreign keys differently. Incidently,
foreign keys are all AFTER triggers, even in 7.4, but I don't understand
why 7.4 doesn't exhaust itself of memory collecting the trigger events,
as is described in the following mailing list post:

http://archives.postgresql.org/pgsql...5/msg00036.php

Also, and this is pure conjecture, this bug may be related to the
following change in the 8.0 release notes:
"Nondeferred AFTER triggers are now fired immediately after completion
of the triggering query, rather than upon finishing the current
interactive command. This makes a difference when the triggering query
occurred within a function: the trigger is invoked before the function
proceeds to its next operation. For example, if a function inserts a new
row into a table, any nondeferred foreign key checks occur before
proceeding with the function."

Regards,
Jeff Davis


Step 1: Create 4 tables
-----------------------------------------
CREATE TABLE r1( i INT PRIMARY KEY );
INSERT INTO r1 VALUES(1);
CREATE TABLE r2( i INT PRIMARY KEY );
INSERT INTO r2 VALUES(1);
CREATE TABLE r3( i INT PRIMARY KEY );
INSERT INTO r3 VALUES(1);
CREATE TABLE r4( i INT PRIMARY KEY );
INSERT INTO r4 VALUES(1);


Step 2: Cause an out of memory condition. The result is an ERROR, as
expected.
-----------------------------------------

BEGIN;

CREATE TABLE crashme (
attr1 INT REFERENCES r1(i),
attr2 INT REFERENCES r2(i),
attr3 INT REFERENCES r3(i),
attr4 INT REFERENCES r4(i),
attr5 TEXT
);

INSERT INTO crashme(attr1,attr2,attr3,attr4,attr5) SELECT 1,1,1,1,'t'
FROM generate_series(1,5000000);


Step 3: Do almost exacly the same thing, except attr5 is INT and not
TEXT type. This causes a PANIC instead of an ERROR. The bug is that this
should be only an ERROR, since everything is the same except the column
type for attr5.
---------------------------------------------------
BEGIN;

CREATE TABLE crashme (
attr1 INT REFERENCES r1(i),
attr2 INT REFERENCES r2(i),
attr3 INT REFERENCES r3(i),
attr4 INT REFERENCES r4(i),
attr5 INT
);

INSERT INTO crashme(attr1,attr2,attr3,attr4,attr5) SELECT 1,1,1,1,1 FROM
generate_series(1,5000000);





---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.