"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 sa
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
[ 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.
> 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
c
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
> c
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 w
