Re: 7.0RC1: possible query and backend problem - Mailing list pgsql-general

From Tom Lane
Subject Re: 7.0RC1: possible query and backend problem
Date
Msg-id 15247.956980884@sss.pgh.pa.us
Whole thread Raw
In response to 7.0RC1: possible query and backend problem  (Michael Blakeley <mike@blakeley.com>)
Responses Re: 7.0RC1: possible query and backend problem
List pgsql-general
Michael Blakeley <mike@blakeley.com> writes:
> I've just upgraded to 7.0RC1 on a Solaris 2.6+patches system (U5 with
> 256MB). I'm having some trouble with a brand-new query, so I don't
> know if this is a new bug or an old one. It has two parts: query
> execution and backend robustness.

>     SELECT id,date_part('epoch',sum(stop-start)),count(*),S1.url,S2.url
>     FROM U WHERE 'now'::datetime-start<'1 month'::interval
>     AND (id=S1.id OR id=S2.id) GROUP BY id,S1.url,S2.url;

>     pqReadData() -- backend closed the channel unexpectedly.
>          This probably means the backend terminated abnormally
>          before or while processing the request.

I've fixed this problem, I think --- the three-way join clause was
confusing the planner :-(.

> I suspect that the problem is that, in my data set, either S1.url or
> S2.url will be null for any given row, and this is causing problems
> for GROUP BY

That shouldn't be a problem, although you do need to be careful
when dealing with NULLs --- it's easy to write the query so that
the WHERE condition will produce NULL, which is interpreted as FALSE.
But the above should work OK, because (NULL OR TRUE) will produce
TRUE.

>> IpcMemoryCreate: shmget failed (Invalid argument) key=5432110,
>> size=144, permission=700

Hmm, that is odd.  The thing that looks peculiar to me is that
it seems to be calculating a different size for the segment than
it did the first time through:

> # ipcs -a
> IPC status from <running system> as of Wed Apr 19 16:45:42 2000
> T         ID      KEY        MODE        OWNER    GROUP  CREATOR
> CGROUP NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME
> Shared Memory:
> m        800   0x0052e32e --rw------- postgres postgres postgres
> postgres      0        120 12737 12737 13:01:36 13:01:36 13:01:36

See the difference?  120 vs 144?  What's causing that I wonder...
and would it explain the failure to reattach?

            regards, tom lane

pgsql-general by date:

Previous
From: "James R. R. Service"
Date:
Subject: Re: Read Only from ODBC
Next
From: Travis Bauer
Date:
Subject: Re: problem with nested views