> > > 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
