Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror
От | Jeff Davis |
---|---|
Тема | Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror |
Дата | |
Msg-id | 1199821190.10057.403.camel@dogma.ljc.laika.com обсуждение исходный текст |
Ответ на | Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror ("Scot Loach" <sloach@sandvine.com>) |
Ответы |
Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: