Re: executor relation handling
Tom Lane <tgl@sss.pgh.pa.us>
Andres Freund <andres@anarazel.de> writes: > I've not really followed this thread, and just caught up to here. It > seems entirely unacceptable to not acquire locks on workers to me. > Maybe I'm missing something, but why do/did the patches in this thread > require that / introduce that? We didn't have that kind of concept > before, no? The group locking stuff should rely / require that kind of > thing, no? I'm possibly confused, but I thought that the design of parallel query involved an expectation that workers didn't need to get their own locks. What we've determined so far in this thread is that workers *do* get their own locks (or did before yesterday), but I'd been supposing that that was accidental not intentional. In any case, I definitely intend that they will be getting their own locks again after the dust has settled. Panic not. 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