| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | Ryan Lowe <rlowe(at)pablowe(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #6497: Error sent to client, but data written anyway |
| Date: | 2012-02-29 21:15:18 |
| Message-ID: | 7955.1330550118@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Christophe Pettus <xof(at)thebuild(dot)com> writes:
> On Feb 29, 2012, at 9:26 AM, Ryan Lowe wrote:
>> Thanks for all the responses, but I think I'm being unclear here.
> The point Tom was making is that this is indistinguishable from the scenario:
> 1. Client sends commit.
> 2. Server successfully commits data.
> 3. Server starts to write response.
> 4. Network fails.
> 5. Client receives abnormal disconnection response from its network connection to the server.
Well, that's the argument as to why the client code has to be capable of
checking whether the commit happened if it's going to attempt a
reconnect and retry. But there's a quite separate question as to
whether the behavior Ryan is claiming for a pre-commit crash is actually
possible. I don't believe it, and I failed to reproduce his test
scenario.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2012-02-29 21:22:43 | Re: BUG #6497: Error sent to client, but data written anyway |
| Previous Message | Christophe Pettus | 2012-02-29 21:05:20 | Re: BUG #6497: Error sent to client, but data written anyway |