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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rlowe(at)pablowe(dot)net
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6497: Error sent to client, but data written anyway
Date: 2012-02-28 21:38:29
Message-ID: 23519.1330465109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-02-28 21:47:06 Re: BUG #6496: Why the SQL is not reported as incorrect? Is there a builtin column named "name"?
Previous Message Devrim GÜNDÜZ 2012-02-28 19:58:58 Re: pgadmin3 update to 1.14.2 erases /usr/bin link