Re: Inadequate executor locking of indexes

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
Subject: Re: Inadequate executor locking of indexes
Date: 2019-02-05 04:15:54
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, 28 Nov 2018 at 01:55, David Rowley <david(dot)rowley(at)2ndquadrant(dot)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

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
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
idxlockmode_and_lock_upgrade_fix_v2.patch application/octet-stream 10.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-02-05 04:46:55 Re: Tighten up a few overly lax regexes in pg_dump's tap tests
Previous Message Michael Paquier 2019-02-05 03:59:12 Re: Feature: temporary materialized views