<p dir="ltr"><br /> On 15 Sep 2013 10:19, "Peter Geoghegan" <<a href="mailto:pg@heroku.com">pg@heroku.com</a>>
wrote:<br/> ><br /> > On Sat, Sep 14, 2013 at 1:57 AM, Greg Stark <<a
href="mailto:stark@mit.edu">stark@mit.edu</a>>wrote:<br /> > > It seems to me that the nature of the problem
isthat there will unavoidably<br /> > > be a nexus between the two parts of the code here. We can try to isolate
it<br/> > > as much as possible but we're going to need a bit of a compromise.<br /><p dir="ltr">> In order
forany of this to really be possible, there'd have to be<br /> > some concession made to my position, as Greg
mentionshere. In other<br /> > words, I'd need buy-in for the general idea of holding locks in shared<br /> >
memoryfrom indexes across heap tuple insertion (subject to a sound<br /> > deadlock analysis, of course). <p
dir="ltr">Actuallythat wasn't what I meant by that.<p dir="ltr">What I meant is that there going to be some code
couplingbetween the executor and btree code. That's purely a question of course structure, and will be true regardless
ofthe algorithm you settle on.<p dir="ltr">What I was suggesting was an api for a function that would encapsulate that
coupling.The executor would call this function which would promise to obtain all the locks needed for both operations
orgive up. Effectively it would be a special btree operation which would have special knowledge of the executor only in
thatit knows that being able to get a lock on two heap buffers is something the executor needs sometimes.<p
dir="ltr">I'mnot sure this fits well with your syntax since it assumes the update will happen at the same time as the
indexlookup but as I said I haven't read your patch, maybe it's not incompatible. I'm writing all this on my phone so
it'smostly just pie in the sky brainstorming. I'm sorry if it's entirely irrelevant.<br />
