I'm trying to clearly understand how foreign key constraints work. I
still need some help.
The PostgreSQL documentation says:
ROW EXCLUSIVE
Conflicts with the SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and
ACCESS EXCLUSIVE lock
modes.
The commands UPDATE, DELETE, and INSERT acquire this lock
Perry Smith [EMAIL PROTECTED] writes:
Looking at the documentation above, I would expect the insert into A to get a
Row exclusive lock for table A. And, I'm guessing it would get an ACCESS
SHARE lock for table B. But this would not prevent the delete from B from
happening at the same time
Hi,
I'm trying to figure out the best way to handle the following situation.
There are two processes, A, and B.
A is a daemon process that performs a select, and then slowly iterates
over the results, performing updates along the way.
It is possible that interactive process B comes along, and
On Tue, 2006-03-28 at 14:56 +0200, David Welton wrote:
There are two processes, A, and B.
A is a daemon process that performs a select, and then slowly iterates
over the results, performing updates along the way.
It is possible that interactive process B comes along, and wants to
change
Try breaking down the A query with LIMIT/OFFSET so that it never holds
locks for long. That way B will not wait for long, if at all, and will
not fail.
Just as a remark, this will only work if the chunks can be processed in
separate transactions. If the whole thing is related and A must be
[ Oops, I missed the reply-to button the first time - sorry for the
repeat, Csaba ]
On 3/28/06, Csaba Nagy [EMAIL PROTECTED] wrote:
Try breaking down the A query with LIMIT/OFFSET so that it never holds
locks for long. That way B will not wait for long, if at all, and will
not fail.
Just
