tom,
I don't think this is the case here, he is doing a select from his own
user defined function, the funciont is emitting the notices, jdbc would
be spinning on reading the notices.
Dave
On Sat, 2003-06-28 at 01:46, Tom Lane wrote:
> Garrick Dasbach <Garrick@musicrebellion.com> writes:
> > Well, we found the problem. Using a Packet Sniffer we found that
> > Postgres was sending Thousands of 8K messages back to our JDBC test
> > Program. Inside these packets were the text from the 'NOTICE' commands
> > we were using to debug our function. We didn't realize that Postgres
> > sent these messages back.
>
> Someone reported a comparable problem recently in libpq: they had an ON
> INSERT trigger that emitted tons of NOTICEs, and they found that a COPY
> into that table would hang up, because libpq's routines to process COPY
> IN data transmission don't bother to look to see if there's any return
> data they ought to read. Sooner or later the return path fills up and
> the kernel blocks the sender (ie, the backend). This is on my to-fix
> list, but I've not gotten to it yet. It sounds like JDBC has a similar
> issue someplace.
>
> 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
>
--
Dave Cramer <Dave@micro-automation.net>
