From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 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-18 23:13:48 |
Message-ID: | CAKJS1f-g6fHxGGyFmjw=H+D7-esC6ECjDvvVYHK1oQHcsg2-tQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 12 Feb 2019 at 09:58, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Mon, Feb 11, 2019 at 5:32 AM David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> > 1. Adding a new field to RangeTblEntry to indicate the operation type
> > that's being performed on the relation; or
> > 2. Adding a Bitmapset field to PlannerGlobal that sets the rtable
> > indexes of RangeTblEntry items that belong to DELETEs and ignore these
> > when setting resultRelids in finalize_lockmodes().
> >
> > For #2, the only place I can see to do this is
> > add_rtes_to_flat_rtable(), which would require either passing the
> > PlannerInfo into the function, or at least its parse's commandType.
> >
> > I don't really like either, but don't have any other ideas at the moment.
>
> But we would still need the same lock level upgrade logic on indexes
> for cases like CTE with a mix of INSERT, UPDATE and DELETE on the same
> relation I think. #1 seems like a better solution to me.
I think I'd rather find some way to do it that didn't denormalise the
parse nodes like that. It seems very strange to have a CmdType in the
Query struct, and then another set of them in RangeTblEntry. Besides
bloating the size of the RangeTblEntry struct a bit, it also could
lead to inconsistency bugs where the two CmdTypes differ, for some
reason.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-18 23:15:00 | Re: Delay locking partitions during INSERT and UPDATE |
Previous Message | David Rowley | 2019-02-18 22:56:22 | Re: Delay locking partitions during INSERT and UPDATE |