On Wed, 9 Jun 2004, Stephan Szabo wrote:
> On Wed, 9 Jun 2004, Alvaro Herrera wrote:
>
> > On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> > > On Sat, 29 May 2004, Alvaro Herrera wrote:
> >
> > > > Ah, this seems to work. I'll implement it and I'll let you know how it
> > > > goes.
> > >
> > > Ugh... There's one further wrinkle I hadn't thought about, imagine the
> > > following:
> >
> > Ok Stephan, thank you very much for your help. I implemented this and
> > it seems to work, at least on my (limited?) test scenario. If you have
> > some spare time I'd like you to test it and see if you can break it (I
> > posted it to -patches yesterday).
>
> Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> at work, so I'm doing it during compilations and such.)
>
> I made a file ins with a 1000000 line copy to a table named fk with the
> value 1, and then if I do the following:
>
> create table pk(a int primary key);
> create table fk(a int references pk(a) initially deferred);
> insert into pk values (1);
>
> begin;
> begin;
> \i ins
> \i ins
> rollback;
> \i ins
> commit;
>
> It appears to exception on the third \i ins with the tail_thisxact
> pointing into a bad place.
Okay - I think I see what's going on here.
It looks like deferredTriggerInvokeEvents is being run (immediate_only),
but since deferredTriggers->events_imm is NULL it's using
deferredTriggers->events as the start of the list to check, but this value
isn't getting reset in DeferredTriggerEndSubXact in the case that the
entire list was created in an aborted subtransaction.
