On Wed, 28 Nov 2018 at 01:55, David Rowley <david.row...@2ndquadrant.com> wrote: > If this looks like a good path to go in, then I can produce something > a bit more finished. I'm just a bit unsure when exactly I can do that > as I'm on leave and have other commitments to take care of.
This patch is still on my list, so I had another look at what I did back in November... I've changed a couple of things: 1. Changed nodeBitmapIndexscan.c now properly uses the RangeTblEntry's idxlockmode field. 2. Renamed a few variables in finalize_lockmodes(). I'm keen to get some feedback if we should go about fixing things this way. One thing that's still on my mind is that the parser is still at risk of lock upgrade hazards. This patch only fixes the executor. I don't quite see how it would be possible to fix the same in the parser. I was also looking at each call site that calls ExecOpenIndices(). I don't think it's great that ExecInitModifyTable() has its own logic to skip calling that function for DELETE. I wondered if it shouldn't somehow depend on what the idxlockmode is set to. I also saw that apply_handle_delete() makes a call to ExecOpenIndices(). I don't think that one is needed, but I didn't test anything to make sure. Maybe that's for another thread anyway. Updated patch is attached. Adding to the March commitfest as a bug fix. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
idxlockmode_and_lock_upgrade_fix_v2.patch
Description: Binary data
