Postgres Pro
Downloads
Home   >   mailing lists

Thread: commit after dead lock

commit after dead lock

From
Gaetano Mendola
Date:
Hi all,
is it normal that postgres dont complain
doing a commit after a deadlock ?

kalman=# select * from test where a = 5 for update;
ERROR:  deadlock detected
DETAIL:  Process 4144 waits for ShareLock on transaction 40180; blocked
by process 4141.
Process 4141 waits for ShareLock on transaction 40181; blocked by
process 4144.
kalman=# commit;
COMMIT
kalman=#


Regards
Gaetano Mendola

Re: commit after dead lock

From
Stephan Szabo
Date:
On Fri, 30 Jan 2004, Gaetano Mendola wrote:

> Hi all,
> is it normal that postgres dont complain
> doing a commit after a deadlock ?
>
> kalman=# select * from test where a = 5 for update;
> ERROR:  deadlock detected
> DETAIL:  Process 4144 waits for ShareLock on transaction 40180; blocked
> by process 4141.
> Process 4141 waits for ShareLock on transaction 40181; blocked by
> process 4144.
> kalman=# commit;
> COMMIT

It's not really any different than other errors. The commit doesn't
complain (although it also doesn't actually commit anything).

sszabo=# begin;
BEGIN
sszabo=# select * from foo;
ERROR:  relation "foo" does not exist
sszabo=# commit;
COMMIT

Re: commit after dead lock

From
Tom Lane
Date:
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> It's not really any different than other errors. The commit doesn't
> complain (although it also doesn't actually commit anything).

People have occasionally suggested that the command tag from a COMMIT
should read "ABORT" or "ROLLBACK" if the transaction was previously
aborted.  I don't have a strong feeling about it one way or the other.
It'd clearly be helpful for human users, but I could see it confusing
programs that expect the existing behavior of command tag always
matching command.

            regards, tom lane

Re: commit after dead lock

From
Gaetano Mendola
Date:
Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>
>>It's not really any different than other errors. The commit doesn't
>>complain (although it also doesn't actually commit anything).
>
>
> People have occasionally suggested that the command tag from a COMMIT
> should read "ABORT" or "ROLLBACK" if the transaction was previously
> aborted.  I don't have a strong feeling about it one way or the other.
> It'd clearly be helpful for human users, but I could see it confusing
> programs that expect the existing behavior of command tag always
> matching command.


Well, I agree but I think that is better at least rise a
warning.


regards
Geetano Mendola