rl...@pablowe.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
