Thread: v7.1 error ... SELECT converted to a COPY?
Okay, maybe this query isn't quite as simple as I think it is, but does
this raise any flags for anyone? How did I get into a COPY? It appears
re-creatable, as I've done it twice so far ...
eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber;
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> \.
Unknown protocol character 'J' read from backend. (The protocol character is the first character the backend sends in
responseto a query it receives).
PQendcopy: resetting connection
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> Okay, maybe this query isn't quite as simple as I think it is, but does
> this raise any flags for anyone? How did I get into a COPY? It appears
> re-creatable, as I've done it twice so far ...
> eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber;
> Backend sent D message without prior T
> Backend sent D message without prior T
At a guess, you're running out of memory on the client side for the
SELECT results (did you really want a not-equal rather than equal
constraint there!?) --- libpq tends not to cope with this too
gracefully. Someone oughta fix that...
regards, tom lane
On Mon, 30 Apr 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > Okay, maybe this query isn't quite as simple as I think it is, but does > > this raise any flags for anyone? How did I get into a COPY? It appears > > re-creatable, as I've done it twice so far ... > > > eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber; > > Backend sent D message without prior T > > Backend sent D message without prior T > > At a guess, you're running out of memory on the client side for the > SELECT results (did you really want a not-equal rather than equal > constraint there!?) Yup, want to figure out which ones are in the egi table that I hadn't transfer'd over yet ... tried it with a NOT IN ( SELECT ... ) combination, but an explain of that showed two sequential searches on the tables, so am working on fixing that ...
The Hermit Hacker wrote: > > On Mon, 30 Apr 2001, Tom Lane wrote: > > > The Hermit Hacker <scrappy@hub.org> writes: > > > Okay, maybe this query isn't quite as simple as I think it is, but does > > > this raise any flags for anyone? How did I get into a COPY? It appears > > > re-creatable, as I've done it twice so far ... > > > > > eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber; > > > Backend sent D message without prior T > > > Backend sent D message without prior T > > > > At a guess, you're running out of memory on the client side for the > > SELECT results (did you really want a not-equal rather than equal > > constraint there!?) > > Yup, want to figure out which ones are in the egi table that I hadn't > transfer'd over yet ... tried it with a NOT IN ( SELECT ... ) combination, > but an explain of that showed two sequential searches on the tables, did you do it as select e.idnumber,e.password from egi ewhere e.idnumber not in (select idnumber from auth_info a where e.idnumber = a.idnumber) ; to smarten up the optimizer about using a join ? I guess that it can be done using outer joins and testing the "outer2 part for IS NULL in 7.1 ------------------- Hannu