Re: executor relation handling
Tom Lane <tgl@sss.pgh.pa.us>
Attachments
- v11-add-rte-rellockmode-field.patch (text/x-diff) patch v11
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
Commits
-
Avoid O(N^2) cost in ExecFindRowMark().
- f9eb7c14b08d 12.0 landed
-
Remove some unnecessary fields from Plan trees.
- 52ed730d511b 12.0 landed
-
Restore sane locking behavior during parallel query.
- 29ef2b310da9 12.0 landed
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 landed
-
In the executor, use an array of pointers to access the rangetable.
- d73f4c74dd34 12.0 landed
-
Centralize executor's opening/closing of Relations for rangetable entries.
- 9ddef36278a9 12.0 landed
-
Change executor to just Assert that table locks were already obtained.
- 9a3cebeaa7fd 12.0 landed
-
Change rewriter/planner/executor/plancache to depend on RTE rellockmode.
- 6e35939febf8 12.0 landed
-
Add assertions that we hold some relevant lock during relation open.
- b04aeb0a053e 12.0 landed
-
Create an RTE field to record the query's lock mode for each relation.
- fdba460a26af 12.0 landed