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. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html