Hi,
On 2013-12-17 18:27:26 -0300, Alvaro Herrera wrote:
Well, it would help if those cases weren't dead code. Neither
heap_update nor heap_delete are ever called in the no wait case at
all.
Yea, that sucks, maybe we ought to change that in HEAD. But there very
well might be external
Andres Freund wrote:
I have to say, it makes me really uncomfortable to take such
shortcuts. In other branches we are doing liveliness checks with
MultiXactIdIsRunning() et al. Why isn't that necessary here? And how
likely is that this won't cause breakage somewhere down the line because
Alvaro Herrera wrote:
Andres Freund wrote:
I have to say, it makes me really uncomfortable to take such
shortcuts. In other branches we are doing liveliness checks with
MultiXactIdIsRunning() et al. Why isn't that necessary here? And how
likely is that this won't cause breakage
Andres Freund wrote:
On 2013-12-16 17:43:37 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
This POC patch changes the two places in HeapTupleSatisfiesUpdate that
need to be touched for this to work. This is probably too simplistic,
in that I make the involved cases return
Alvaro Herrera wrote:
Well, it would help if those cases weren't dead code. Neither
heap_update nor heap_delete are ever called in the no wait case at
all. Only heap_lock_tuple is, and I can't see any misbehavior there
either, even with HeapTupleBeingUpdated returned when there's a
Alvaro Herrera wrote:
The fix for the immediate bug is to add some code to HTSU so that it
checks for locks by other transactions even when the tuple was created
by us. I haven't looked at the other tqual routines yet, but I imagine
they will need equivalent fixes.
This POC patch changes
Alvaro Herrera wrote:
This POC patch changes the two places in HeapTupleSatisfiesUpdate that
need to be touched for this to work. This is probably too simplistic,
in that I make the involved cases return HeapTupleBeingUpdated without
checking that there actually are remote lockers, which is
On 2013-12-16 17:43:37 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
This POC patch changes the two places in HeapTupleSatisfiesUpdate that
need to be touched for this to work. This is probably too simplistic,
in that I make the involved cases return HeapTupleBeingUpdated without
In 9.3 I can delete the parent of a parent-child relation if the child row
is an uncommitted insert and I first update the parent.
USER1:
drop table child;
drop table parent;
create table parent (i int, c char(3));
create unique index parent_idx on parent (i);
insert into parent values (1,
Daniel Wood wrote:
In 9.3 I can delete the parent of a parent-child relation if the child row
is an uncommitted insert and I first update the parent.
Interesting test case, thanks. I traced through it and promptly noticed
that the problem is that HeapTupleSatisfiesUpdate is failing to consider
10 matches
Mail list logo
