Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
---
Richard Huxton wrote:
Florian G. Pflug
Florian G. Pflug wrote:
Is there consensus what the correct behaviour should be for
self-referential updates in read-committed mode? Does the SQL Spec
have anything to say about this?
This seems to have gone all quiet. Do we need a TODO to keep a note of
it? Just correct behaviour for
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kind of updates. I'm
Richard Huxton wrote:
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
UPDATE 0
?
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd say. Try the following
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd
Hiroshi Inoue wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just
Florian G. Pflug wrote:
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
snip
Bit more than just normal rule confusion I'd say. Try the following
two statements in parallel (assuming you've just run the previous):
UPDATE test SET dt='c';
UPDATE test SET dt='x' FROM
13 matches
Mail list logo
