Обсуждение: reliable way to crash postgres :)

Hi,

I think I've found a pretty reliable way to crash my pgsql backend.

To reproduce (at least on 6.5.1.) enter:
  select * from pg_attribute where (case when 1=1 then     (attname='testname') else (0=1) end);

I chose the pg_attribute table because it exists on every system :),
while the query does not look to make too much sense I orignally
wanted to implement different WHERE conditions based on another
condition (here just 1=1 :-)

Regards,

-- 
Jens Glaser     Am Holderstrauch 13, 36041 Fulda, 0661/9429507    jens@jens.de

Jens Glaser <jens@helena.jens.de> writes:
>    select * from pg_attribute where (case when 1=1 then 
>      (attname='testname') else (0=1) end);

This is fixed in current sources, but for some reason it didn't get
back-patched into REL6_5.  Done now.  Here's the patch if you're in a
hurry.

*** backend/optimizer/path/indxpath.c.orig    Sat Jun 19 00:54:14 1999
--- backend/optimizer/path/indxpath.c    Tue Sep 14 16:26:02 1999
***************
*** 585,596 ****     Oid            restrict_op = InvalidOid;     bool        isIndexable = false; 
!     if (or_clause((Node *) clause) ||
!         not_clause((Node *) clause) || single_node((Node *) clause))
!         return (RestrictInfo *) NULL;
!      leftop = get_leftop(clause);     rightop = get_rightop(clause);      /*      * If this is not a join clause,
checkfor clauses of the form:
 
--- 585,597 ----     Oid            restrict_op = InvalidOid;     bool        isIndexable = false; 
!     /* Clause must be a binary opclause. */
!     if (! is_opclause((Node *) clause))
!         return NULL;     leftop = get_leftop(clause);     rightop = get_rightop(clause);
+     if (! leftop || ! rightop)
+         return NULL;      /*      * If this is not a join clause, check for clauses of the form:

        regards, tom lane

hi i was wondering if multi threading will be enabled soon?

also
a prob im having which might be query related but a todo as well
is that i have a 1.3 mil row db
when i try to select all i get memory out type errors, either system wide or
droping the backend

even when i go over 1/4 of the size this happens, can there be some sort of
improvements in the memory handling here too?

or is this an sql technique i dont realize?

basically im selecting rows from the 1.3 mil table and inserting certain
columns into another after some processing

im basically using
select field1,field2 ,field3 from table

and the preprocess and
insert into othertable values field1 ,filed2 ,field3

even if i reduce the select statement to half the size of the first table it
still cans out

any help appreciatted
!

Clayton Cottingham <drfrog@smartt.com> writes:
> hi i was wondering if multi threading will be enabled soon?

Huh?  We already have multiple backends, what advantage would
there be to using threads?

> is that i have a 1.3 mil row db when i try to select all i get memory
> out type errors, either system wide or droping the backend

The problem is probably at the application end --- libpq is built on
the model that it can collect the entire query result in memory and
then give the application random access to that array.  So if the
query result won't fit in the space available to the application,
trouble.  I don't see why this would affect anything else in your
system, though, unless the app uses up all available swap space and
holds it for a while before crashing...

What you probably want to do instead of a straight SELECT is use
DECLARE CURSOR and FETCH to retrieve the table a few dozen/hundred
rows at a time.
        regards, tom lane