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:
> 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
>
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 externa
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
> n
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
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 wit
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
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
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 conside
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, 'AAA');
10 matches
Mail list logo
