From: | DaVinci <bombadil(at)wanadoo(dot)es> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: transaction safety |
Date: | 2001-02-14 12:50:10 |
Message-ID: | 20010214135010.A2668@fangorn.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Feb 14, 2001 at 06:34:01AM -0500, Jan Wieck wrote:
> DaVinci wrote:
> > Problem is with referential integrity like you say. But I don't understand
> > well reason. Interlocks should appear only when values of referenced tables
> > are changed, added or removed, shouldn't they?. But that is not the case. I
> > only insert in table "aviso".
> >
> > Is this normal?
>
> Maybe.
>
> The problem is, that a referential integrity constraint needs
> to ensure that from the moment the constraint got checked
> until your INSERT got made persistent (COMMIT), nobody else
> has a chance to kick out the referenced key.
>
> Due to the lack of the ability to put a shared row lock with
> a SELECT, we currently use FOR UPDATE, placing an exclusive
> lock onto the referenced key.
I understand this but, why then other changes on "aviso" get locked?. My
first impression is that only referenced keys should be, but not a table
that references them.
If this works so for now, is any plan to change in future?.
> In your case it might help to make the constraints INITIALLY
> DEFERRED. That causes that the checks are delayed until
> COMMIT, so it shortens the time the lock is present.
Thanks!. That works fine.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Mikhail V. Majorov | 2001-02-14 13:00:23 | Parameters if trigger... |
Previous Message | Jan Wieck | 2001-02-14 12:20:13 | Re: Bad book review |