From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Jon Swinth <jswinth(at)atomicpc(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Fix FK deadlock, but no magic please |
Date: | 2003-01-17 23:34:18 |
Message-ID: | 20030117153016.C28387-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 17 Jan 2003, Jon Swinth wrote:
> Oracle's behavior AFAIK depends on which lock you are talking about. If you
> are talking about not being able to get a read lock then Oracle just blocks
> until it can, indefinately unless a deadlock is detected.
>
> If you are talking about a write lock, that depends on how the write lock is
> called. If you call SELECT ... FOR UPDATE or call UPDATE/DELETE without
> locking first then again Oracle will block until it can get the lock. If you
> call SELECT ... FOR UPDATE NOWAIT then Oracle will throw a specific SQL
> exception if a lock cannot be granted immediately. This allows you to do a
> sleep and retry in your code so that you only wait for a lock so long:
I was wondering about the NOWAIT specific behavior particularly. You
could send a notice (completion condition) I guess, but an actual
exception wouldn't work.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-01-17 23:37:28 | Re: temporary tables |
Previous Message | Jon Swinth | 2003-01-17 23:25:48 | Re: Fix FK deadlock, but no magic please |