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. -----Original Message----- From: Jeff Davis [mailto:[EMAIL PROTECTED] 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. > > However, PostgreSQL does not look at the # of bytes written and > continue sending after that many bytes. PostgreSQL actually simply > clears its buffer of bytes to send on this error, in this code: > > pqcomm.c:1075 > /* > * We drop the buffered data anyway so that processing can > * continue, even though we'll probably quit soon. > */ > PqSendPointer = 0; > return EOF; > > > The result as I saw on a system where this was occurring, was that > when PostgreSQL was sending back a large result set, there was simply > 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 = 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
