Skip site navigation (1) Skip section navigation (2)

Re: BUG #6497: Error sent to client, but data written anyway

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <rlowe(at)pablowe(dot)net>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6497: Error sent to client, but data written anyway
Date: 2012-02-28 22:01:40
Message-ID: 4F4CFA640200002500045CAC@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> rlowe(at)pablowe(dot)net writes:
>> There is an edge case where Postgres will return an error to the
>> client, but commit the operation anyway, thus breaking the
>> contract with the client:
> 
>> postgres=# begin; insert into s.t (c) values (1);
>> <postgres process core dumps (note that the forked processes were
>> not affected)>
>> postgres=# commit;
>> <this returns an error to the application>
>> <postgress process restarts>
>> The data is now on both the master and slave, but the application
>> believes that the transaction was rolled back.  A well-behaved
>> application will dutifully retry the transaction because it
>> *should* have rolled back.  However, the data is there so we'll
>> have had the transaction execute *twice*.
> 
> Huh?  If the backend dumped core before you sent it the commit,
> the data will certainly not be committed.  It might be physically
> present on disk, but it won't be considered valid.
 
I suppose that there is a window of time between the commit becoming
effective and the return to the application which, from a user
perspective, would be hard to distinguish from what the OP
described.  I don't really see how that can be avoided, though,
short of a transaction manager using 2PC.  Any time the server
crashes while a COMMIT is pending, one must check to see whether it
"took".
 
As long as the client application sees the connection as dead in
this situation, I think PostgreSQL is doing everything just as it
should.
 
-Kevin

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2012-02-28 22:42:10
Subject: Re: BUG #6497: Error sent to client, but data written anyway
Previous:From: Rikard PavelicDate: 2012-02-28 21:49:22
Subject: Re: BUG #6489: Alter table with composite type/table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group