| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: executor relation handling |
| Date: | 2018-09-28 08:00:00 |
| Message-ID: | 987ce765-7dac-fb14-815b-6b4e0d7c7c5a@lab.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018/09/27 18:15, David Rowley wrote:
> I've just completed a review of the v5 patch set. I ended up just
> making the changes myself since Amit mentioned he was on leave for a
> few weeks.
>
> Summary of changes:
>
> 1. Changed the way we verify the lock already exists with debug
> builds. I reverted some incorrect code added to LockRelationOid that
> seems to have gotten broken after being rebased on f868a8143a9. I've
> just added some functions that verify the lock is in the
> LockMethodLocalHash hashtable.
Thanks. I guess I wasn't terribly happy with my job of rebasing on top of
f868a8143a9, because that commit had made the result of
LockAcquireExtended a bit ambiguous for me.
I like the new CheckRelationLockedByUs() and LocalLockExists() functions
that you added to lock manager.
> 2. Fixed some incorrect lock types being passed into
> addRangeTableEntryForRelation()
>
> 3. Added code in addRangeTableEntryForRelation to verify we actually
> hold the lock that the parameter claims we do. (This found all the
> errors I fixed in #2)
I see that I'd falsely copy-pasted AccessShareLock in transformRuleStmt,
which you've corrected to AccessExclusiveLock. I was not sure about other
cases where you've replaced NoLock by something else, because they won't
be checked or asserted, but perhaps that's fine.
> 4. Updated various comments outdated by the patches
> 5. Updated executor README's mention that we close relations when
> calling the end node function. This is now handled at the end of
> execution.
Thank you. I see that you also fixed some useless code that I had left
lying around as result of code movement such as the following dead code:
@@ -2711,9 +2711,7 @@ ExecEndModifyTable(ModifyTableState *node)
{
int i;
- /*
- * close the result relation(s) if any, but hold locks until xact commit.
- */
+ /* Perform cleanup. */
for (i = 0; i < node->mt_nplans; i++)
{
ResultRelInfo *resultRelInfo = node->resultRelInfo + i;
@@ -2728,7 +2726,6 @@ ExecEndModifyTable(ModifyTableState *node)
/* Close indices and then the relation itself */
ExecCloseIndices(resultRelInfo);
heap_close(resultRelInfo->ri_RelationDesc, NoLock);
- resultRelInfo++;
}
> 6. Renamed nominalRelation to targetRelation. I think this fits
> better since we're overloading the variable.
That makes sense to me.
> 7. Use LOCKMODE instead of int in some places.
> 8. Changed warning about relation not locked to WARNING instead of NOTICE.
Oops, think I'd forgotten to do that myself.
> 9. Renamed get_unpruned_rowmarks() to get_nondummy_rowmarks(). Pruning
> makes me think of partition pruning but the function checks for dummy
> rels. These could be dummy for reasons other than partition pruning.
Makes sense too.
> I've attached a diff showing the changes I made along with the full
> patches which I tagged as v6.
Thanks a lot for working on that. I've made minor tweaks, which find in
the attached updated patches (a .diff file containing changes from v6 to
v7 is also attached).
Regards,
Amit
| Attachment | Content-Type | Size |
|---|---|---|
| v6_to_v7_changes.diff | text/plain | 2.8 KB |
| v7-0001-Don-t-lock-range-table-relations-in-the-executor.patch | text/plain | 44.0 KB |
| v7-0002-Remove-useless-fields-from-planner-nodes.patch | text/plain | 43.4 KB |
| v7-0003-Prune-PlanRowMark-of-relations-that-are-pruned-fr.patch | text/plain | 2.4 KB |
| v7-0004-Revise-executor-range-table-relation-opening-clos.patch | text/plain | 39.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-09-28 08:21:02 | Re: executor relation handling |
| Previous Message | Peter Eisentraut | 2018-09-28 07:35:48 | Re: transction_timestamp() inside of procedures |