Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror

Yes that is what I am trying to explain.
So I think this is still a bug that should be fixed in the backend code.

scot.
=20

-----Original Message-----
From: Jeff Davis [mailto:pgsql@j-davis.com]=20
Sent: Tuesday, January 08, 2008 2:40 PM
To: Scot Loach
Cc: pgsql-bugs@postgresql.org
Subject: RE: [BUGS] BUG #3855: backend sends corrupted data
onEHOSTDOWNerror

On Tue, 2008-01-08 at 14:06 -0500, Scot Loach wrote:
> I agree this would be fine if PostgreSQL works the way you say below.
>=20
> However, PostgreSQL does not look at the # of bytes written and=20
> continue sending after that many bytes.  PostgreSQL actually simply=20
> clears its buffer of bytes to send on this error, in this code:
>=20
> pqcomm.c:1075
>         /*
>          * We drop the buffered data anyway so that processing can
>          * continue, even though we'll probably quit soon.
>          */
>         PqSendPointer =3D 0;
>         return EOF;
>=20
>=20
> The result as I saw on a system where this was occurring, was that=20
> when PostgreSQL was sending back a large result set, there was simply=20
> a fragment of it missing.

I think I see what you are saying. I was thinking about fe-misc.c, where
it explicitly says (in the default case of a switch statement of the
return value):

/* We don't assume it's a fatal error... */
conn->outCount =3D 0;
return -1;

(but that's on the frontend, obviously)

I think the problem you're talking about comes from the callers of
pq_putmessage, which simply ignore any return value at all (and thus do
not retransmit the message). I agree that is a problem (assuming I
understand what's going on).

Regards,
    Jeff Davis