From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: executor relation handling |
Date: | 2018-09-29 22:05:41 |
Message-ID: | 23870.1538258741@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I started poking at this. I thought that it would be a good cross-check
> to apply just the "front half" of 0001 (i.e., creation and population of
> the RTE lockmode field), and then to insert checks in each of the
> "back half" places (executor, plancache, etc) that the lockmodes they
> are computing today match what is in the RTE.
> Those checks fell over many times in the regression tests.
Here's a version that doesn't fall over (for me), incorporating fixes
as I suggested for points 1 and 2, and weakening the back-half assertions
enough to let points 3 and 4 succeed. I'm inclined to commit this to see
if the buildfarm can find any problems I missed.
Some cosmetic changes:
* I renamed the RTE field to rellockmode in the name of greppability.
* I rearranged the order of the arguments for
addRangeTableEntryForRelation to make it more consistent with the
other addRangeTableEntryXXX functions.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v11-add-rte-rellockmode-field.patch | text/x-diff | 30.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-09-29 22:19:23 | Re: [HACKERS] proposal: schema variables |
Previous Message | Arthur Zakirov | 2018-09-29 21:56:38 | Re: libpq host/hostaddr/conninfo inconsistencies |