Обсуждение: FW: query problem "server sent binary data ... without prior row description ..."

Not sure if this is a repeat request, sorry if you receive it twice.

Thanks,

Bill Jones
Systems Architect
Middleware Services
Wells Fargo Services Company
Office --415.222.5226
PCS -- 415.254.3831 (4152543831@mobile.att.net)

Views expressed are mine. Only in unusual circumstances are they shared by
my employer.
    I'm having a problem with postgres on HPUX. My version is:
    VERSION = 'PostgreSQL 7.2.2 on hppa2.0w-hp-hpux11.11,
compiled by aCC -Ae'
    I'm trying to do a query and it consistently gives the
following errors:
    wily=# \a    Output format is unaligned.    wily=# \f ';'    Field separator is ';'.    wily=# \t    Showing only
tuples.
    wily=# select * from wt_metric_backup where intended_end_ts
< '2002-08-16 00:00:00.000-7';
    the query runs for 10 minutes or so, then outputs:
    server sent binary data ("B" message) without prior row
description ("T" message)    server sent binary data ("B" message) without prior row
description ("T" message)    server sent binary data ("B" message) without prior row
description ("T" message)    unexpected character n following empty query response ("I"
message)    server sent data ("D" message) without prior row description
("T" message)    server sent data ("D" message) without prior row description
("T" message)    server sent binary data ("B" message) without prior row
description ("T" message)
    then it prompts me for some input:
    Enter data to be copied followed by a newline.    End with a backslash and a period on a line by itself.    >> \.
server sent binary data ("B" message) without prior row
 
description ("T" message)    unexpected response from server; first received character
was "0"    lost synchronization with server, resetting connection    Asynchronous NOTIFY 'ntsTask|perform:Response Time
(mccoust
r@ <mailto:r@> ' from backend with pid 1667460981 received.
    I've tried this several times. After I got the error the
first time I ran a vacuum analysis on the table and added an index on the
query field (wt_metric_backup.intended_end_ts) but I get the same results.
The error log doesn't show anything unusual until after I kill the query.
    Looks like it's losing packets/messages (server sent binary
data ("B" message) without prior row description ("T" message)), but the
errors are consistent between attempts - I would expect packet loss to be
random. Simpler queries such as:
    select min(intended_end_ts) from wt_metric_backup;
    work okay.
    Any ideas?



Thanks,

Bill Jones
Systems Architect
Middleware Services
Wells Fargo Services Company
Office --415.222.5226
PCS -- 415.254.3831 (4152543831@mobile.att.net)

Views expressed are mine. Only in unusual circumstances are they shared by
my employer.

On Thu, 26 Sep 2002 jonesbl@WellsFargo.COM wrote:

>         I'm having a problem with postgres on HPUX. My version is:
>
>         VERSION = 'PostgreSQL 7.2.2 on hppa2.0w-hp-hpux11.11,
> compiled by aCC -Ae'
>
>         I'm trying to do a query and it consistently gives the
> following errors:
>
>         wily=# \a
>         Output format is unaligned.
>         wily=# \f ';'
>         Field separator is ';'.
>         wily=# \t
>         Showing only tuples.
>
>         wily=# select * from wt_metric_backup where intended_end_ts
> < '2002-08-16 00:00:00.000-7';
>
>         the query runs for 10 minutes or so, then outputs:

How much data is that sending?  The client library is going to try to
buffer the entire result set.

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> On Thu, 26 Sep 2002 jonesbl@WellsFargo.COM wrote:
>> the query runs for 10 minutes or so, then outputs:

> How much data is that sending?  The client library is going to try to
> buffer the entire result set.

And, in fact, this is the typical behavior when it runs out of memory
for the result set :-( ... it loses track of the fact that it was
receiving a result set at all, and starts spitting out complaints
that it's not in the right state as it receives subsequent rows.
(That should be fixed someday, but no one's got round to it.)

Consider using a cursor so you can FETCH a reasonable number of rows
at a time.
        regards, tom lane