On 15 Sep 2013 10:19, "Peter Geoghegan" <p...@heroku.com> wrote: > > On Sat, Sep 14, 2013 at 1:57 AM, Greg Stark <st...@mit.edu> wrote: > > It seems to me that the nature of the problem is that there will unavoidably > > be a nexus between the two parts of the code here. We can try to isolate it > > as much as possible but we're going to need a bit of a compromise.
> In order for any of this to really be possible, there'd have to be > some concession made to my position, as Greg mentions here. In other > words, I'd need buy-in for the general idea of holding locks in shared > memory from indexes across heap tuple insertion (subject to a sound > deadlock analysis, of course). Actually that wasn't what I meant by that. What I meant is that there going to be some code coupling between the executor and btree code. That's purely a question of course structure, and will be true regardless of the algorithm you settle on. 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 or give up. Effectively it would be a special btree operation which would have special knowledge of the executor only in that it knows that being able to get a lock on two heap buffers is something the executor needs sometimes. I'm not sure this fits well with your syntax since it assumes the update will happen at the same time as the index lookup 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's mostly just pie in the sky brainstorming. I'm sorry if it's entirely irrelevant.
