> > > void
> > > heap_mark4fk_lock_acquire(Relation relation, HeapTuple tuple) {
Just wonder how are you going to implement it - is it by using
some kind of "read-locks", ie FK transaction "locks" PK to prevent
delete (this is known as "pessimistic" approach)?
About two years ago we discussed with
On Fri, 15 Nov 2002, Mikheev, Vadim wrote:
> Just wonder how are you going to implement it - is it by using
> some kind of "read-locks", ie FK transaction "locks" PK to prevent
> delete (this is known as "pessimistic" approach)?
> About two years ago we discussed with Jan "optimistic" approach
> w
On Fri, 15 Nov 2002, Manfred Koizar wrote:
> On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
> <[EMAIL PROTECTED]> wrote:
> >Right now, I know that it has a hole that lets through invalid data
>
> Stephan, your patch has been posted to -general (Subject: Re:
> [GENERAL] Help..Help...). Is
On Wed, 13 Nov 2002 14:22:51 -0800 (PST), Stephan Szabo
<[EMAIL PROTECTED]> wrote:
>Right now, I know that it has a hole that lets through invalid data
Stephan, your patch has been posted to -general (Subject: Re:
[GENERAL] Help..Help...). Is this version still valid?
> void
> heap_mark4fk_lock_
> After our and the pg7.3 release is out we'll port there and I
> really would like
> to get rid of this restriction with that release than. So it
> would be wonderful
> if that still goes into the final of 7.3.
I'm not a core developer, but I'll tell you right now that there's pretty
much zero ch
Stephan Szabo wrote:
> I've been working on something of the sort. I've got a test patch
> (against about 7.3b2) that I'm trying to validate which cases it does and
> does not work for. I'm still looking for more volunteers if you've got a
> dev system you're willing to use. :)
I'd willing to do
On Wed, 13 Nov 2002, Peter Schindler wrote:
> But, if a lot of inserts happens into the child table and there is a
> mix of short and long running transactions, the likelihood of blocking
> is very high, even the inserts are independent and everything is ok
> (prim. key etc.). This is even more e
I've got a question about the foreign key constraint behavior.
It looks to me that inserts within transactions into a child table, which have the
same FK value back to the parent will block until the first txn will commit or
rollback. (see example below)
This seems to be based on the fact that