Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Scot Loach <sloach(at)sandvine(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror
Date: 2008-01-08 19:39:50
Message-ID: 1199821190.10057.403.camel@dogma.ljc.laika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Scot Loach 2008-01-08 19:40:59 Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror
Previous Message Scot Loach 2008-01-08 19:06:02 Re: BUG #3855: backend sends corrupted data onEHOSTDOWNerror