Joseph Shraibman <jks@xxxxxxxxxxxxxxx> writes:
> It doesn't matter what the query is. The problem happens before it even
> runs the query.
Hmmm ... I see different misbehavior (psql seems to lock up entirely,
it doesn't slow down or eat CPU). But it's still misbehavior.
"psql -n" doesn't have a problem, which says that this is probably a
readline bug rather than our own bug. I think it's probably context
dependent too; I'm pretty sure I've pasted big queries into psql without
a problem while working directly on my work machine, but right now I'm
ssh'd into it from a laptop and I do see a problem.
[ further experimentation... ] A local psql on the laptop doesn't
show a problem either. Both this and the one on the work machine
are 8.1devel using readline-4.2a, so it doesn't seem to be an issue
of different software versions. Maybe readline doesn't like ssh?
[ still further experimentation... ] No, because ssh'ing to my *other*
work machine and running psql there doesn't show a problem either.
Curiouser and curiouser. But it's clearly very context dependent.
You should probably tell us *exactly* what you are running, in every bit
of software between you and psql. My tests here are with (local) Mac OS
X 10.3.8, Apple-supplied X server and xterm terminal, Apple-supplied ssh
(seems to be 3.6.1p1), local psql is current PG sources + readline 4.2a.
The remote that doesn't work nicely is HPUX 10.20, sshd is
openssh-3.7.1p2, current psql sources, readline 4.2a. The remote that
does work nicely is Fedora Core 3, sshd 3.9p1-8.0.1, current psql
sources, readline 4.3-13. I'm not seeing a pattern ...
> Incidentally when I did that I only got back one row. What's up with that?
UNION eliminates duplicates.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
