RE: RE: [GENERAL] update inside transaction violates un ique constraint?
Btree doesn't take into account that tuple was just marked
for update but still alive. Seems it was handled properly in 6.5.X ?Nope. It has been broken a long time...
Ops. Ok...
Vadim
Btree doesn't take into account that tuple was just marked
for update but still alive. Seems it was handled properly in 6.5.X ?Nope. It has been broken a long time...
Hmm, as I remember, Hiroshi fixed something in this area for 7.0.X.
Hiroshi?
Probably, his fix somehow disappeared from CVS?
Diff against 7.0.2 sources attached.
Vadim
2 Marc - please add this to upcoming 7.0.3
Attachments:
DF.txttext/plain; name=DF.txtDownload
*** src/backend/utils/time/tqual.c.orig Tue Jan 25 21:57:36 2000
--- src/backend/utils/time/tqual.c Tue Sep 26 16:43:26 2000
***************
*** 441,447 ****
--- 441,451 ----
}
if (TransactionIdIsCurrentTransactionId(tuple->t_xmax))
+ {
+ if (tuple->t_infomask & HEAP_MARKED_FOR_UPDATE)
+ return true;
return false;
+ }
if (!TransactionIdDidCommit(tuple->t_xmax))
{
Import Notes
Resolved by subject fallback
"Mikheev, Vadim" wrote:
Btree doesn't take into account that tuple was just marked
for update but still alive. Seems it was handled properly in 6.5.X ?Nope. It has been broken a long time...
Hmm, as I remember, Hiroshi fixed something in this area for 7.0.X.
Hiroshi?
Probably, his fix somehow disappeared from CVS?
Diff against 7.0.2 sources attached.Vadim
2 Marc - please add this to upcoming 7.0.3
Hmm,it seems that both current and REL7_0_PATCHES
have already been changed.
I committed the the change to current tree and
asked Tatsuo to commit it to REL7_0_PATCHES tree.
Regards.
Hiroshi Inoue
Hmm,it seems that both current and REL7_0_PATCHES
have already been changed.
I committed the the change to current tree and
asked Tatsuo to commit it to REL7_0_PATCHES tree.
I also committed current -:))
Vadim
Import Notes
Resolved by subject fallback