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
