Unix Technical Forum

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

This is a discussion on Re: Bug related to out of memory condition (more information) within the pgsql Bugs forums, part of the PostgreSQL category; --> 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 ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Bugs

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-10-2008, 11:20 AM
Jeff Davis
 
Posts: n/a
Default Re: Bug related to out of memory condition (more information)

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

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
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
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 02:15 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com