* Tom Lane [Thu, 12 Feb 2009 19:10:34 -0500]:
[ shrug... ] The "implementation artifact" is that you didn't get a
deadlock *earlier*.
I agree that such behavior is more plain rather than current.
You can't expect to update referenced rows and
referencing rows in the same transaction and not
Konstantin writes:
> I just want to emphasize that mentioned implementation artifact born not
> obvious issues at applications side.
[ shrug... ] The "implementation artifact" is that you didn't get a
deadlock *earlier*. You can't expect to update referenced rows and
referencing rows in the sa
* Heikki Linnakangas [Thu, 12 Feb
2009 19:34:46 +0200]:
It's certainly not ideal. It's an implementation artifact of the way
MVCC and RI triggers work. The purpose is to protect from this
potential
bug:
As I can see you are agree with problem existence and problem will not
be solved soo
Heikki Linnakangas writes:
> Hmm, the comment specifically talks about deferrable RI checks. I wonder
> if we could skip that when there's no deferred triggers queued?
The point of the comment is that if the FK isn't deferred then it will
have been executed already (at completion of the precedin
Konstantin wrote:
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the specia
* Tom Lane [Thu, 12 Feb 2009 10:54:34 -0500]:
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired
a
RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the special code in AfterTrig
Heikki Linnakangas writes:
> Hmm, the first UPDATE should've blocked already. It should've fired a RI
> trigger to lock the parent tuple in shared mode, but it looks like
> that's not happening for some reason.
Read the special code in AfterTriggerSaveEvent. This behavior is
exactly what is ex
Konstantin wrote:
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another be
* Heikki Linnakangas [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another behavior.
Consider ex
Konstantin wrote:
Preparation:
a) Create tables and insert a few rows.
CREATE TABLE parent (pid integer PRIMARY KEY);
CREATE TABLE child (id integer PRIMARY KEY, pid integer REFERENCES
parent(pid) );
INSERT INTO parent VALUES(1);
INSERT INTO child VALUES(1,1);
b) open two sessions via psql to d
The following bug has been logged online:
Bug reference: 4648
Logged by: Konstantin
Email address: kostya2...@rambler.ru
PostgreSQL version: 8.1.16
Operating system: Red Hat Enterprise Linux 4
Description:needless deadlock on tables having foreign-key
Details:
Prepa
11 matches
Mail list logo
