Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: daveh(at)insightdist(dot)com
Cc: hackers(at)postgreSQL(dot)org (PostgreSQL-development)
Subject: Re: [BUGS] General Bug Report: palloc fails with lots of ANDs and ORs
Date: 1998-01-12 16:35:55
Message-ID: 199801121635.LAA05002@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Try changing your OS default memory size. Unsure how to do this under
AIX.

>
>
> ============================================================================
> POSTGRESQL BUG REPORT TEMPLATE
> ============================================================================
>
>
> Your name : David Hartwig
> Your email address : daveh(at)insightdist(dot)com
>
> Category : runtime: back-end: SQL
> Severity : serious
>
> Summary: palloc fails with lots of ANDs and ORs
>
> System Configuration
> --------------------
> Operating System : AIX 4.1
>
> PostgreSQL version : 6.2
>
> Compiler used : native CC
>
> Hardware:
> ---------
> RS 6000
>
> Versions of other tools:
> ------------------------
> NA
>
> --------------------------------------------------------------------------
>
> Problem Description:
> --------------------
> The follow is a mail message describing the problem on the PostODBC mailing list:
>
>
> I have run across this also. We traced it down to a failure in the PostgreSQL server. This occurs under the following conditions.
>
> 1. MS Access
> 2. Specify a multi-part key in the link time setup with postgresql
> 3. Click on table view.
>
> What happens is MS Access takes the following steps. First it selects all possible key values for the table being viewed. I
> suspect it maps the key values to the relative row position in the display. Then it uses the mapping to generate future queries based
> on the mapping and the rows showing on the screen. The queries take the following form:
>
> SELECT keypart1, keypart2, keypart3, col4, col5, col6 ... FROM example_table
> WHERE
> (keypart1 = row1keypartval1 AND keypart2 = row1keypartval2 AND keypart3 = row1keypartval3) OR
> (keypart1 = row2keypartval1 AND keypart2 = row2keypartval2 AND keypart3 = row2keypartval3) OR
> .
> . -- 28 lines of this stuff. Why 28... Why not 28
> .
> (keypart1 = row27keypartval1 AND keypart2 = row27keypartval2 AND keypart3 = row27keypartval3) OR
> (keypart1 = row28keypartval1 AND keypart2 = row28keypartval2 AND keypart3 = row28keypartval3);
>
>
> The PostgreSQL sever chokes on this statement claiming it is out of memory. (palloc) In this example I used a three part key. I
> do not recall if a three part key is enough to trash the backend. It has been a while. I have tried sending these kinds of statements
> directly through the psql monitor and get the same result.
>
>
> --------------------------------------------------------------------------
>
> Test Case:
> ----------
> select c1, c1 c3, c4, c5 ... from example_table
> where
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something) or
> (c1 = something and c2 = something and c3 = something and c4 = something);
>
>
> --------------------------------------------------------------------------
>
> Solution:
> ---------
>
>
> --------------------------------------------------------------------------
>
>
>

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-01-12 17:13:58 Re: [HACKERS] Re: varchar() troubles
Previous Message Thomas G. Lockhart 1998-01-12 15:41:07 Re: varchar() troubles