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
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 |