Thread: pgsql: Allow page lock to conflict among parallel group members.
Allow page lock to conflict among parallel group members. This is required as it is no safer for two related processes to perform clean up in gin indexes at a time than for unrelated processes to do the same. After acquiring page locks, we can acquire relation extension lock but reverse never happens which means these will also not participate in deadlock. So, avoid checking wait edges from this lock. Currently, the parallel mode is strictly read-only, but after this patch we have the infrastructure to allow parallel inserts and parallel copy. Author: Dilip Kumar, Amit Kapila Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/3ba59ccc896e8877e2fbfb8d4f148904cad5f9b0 Modified Files -------------- src/backend/optimizer/plan/planner.c | 13 +++----- src/backend/storage/lmgr/README | 60 ++++++++++++++++++++---------------- src/backend/storage/lmgr/deadlock.c | 9 +++--- src/backend/storage/lmgr/lock.c | 6 ++-- src/backend/storage/lmgr/proc.c | 12 ++++---- 5 files changed, 53 insertions(+), 47 deletions(-)
Hi, On 2020-03-21 03:27:07 +0000, Amit Kapila wrote: > Currently, the parallel mode is strictly read-only, but after this patch > we have the infrastructure to allow parallel inserts and parallel copy. Minor nit: I don't think this gets to fully having the infrastructure for that. It just removes one roadblock. Or am I missing something here? Greetings, Andres Freund
On Sun, Mar 22, 2020 at 5:57 AM Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2020-03-21 03:27:07 +0000, Amit Kapila wrote: > > Currently, the parallel mode is strictly read-only, but after this patch > > we have the infrastructure to allow parallel inserts and parallel copy. > > Minor nit: I don't think this gets to fully having the infrastructure > for that. It just removes one roadblock. Or am I missing something here? > AFAIU, after this, we don't have more roadblocks for parallel inserts, copy or similar operations where workers will be able to perform insert operation, surely there is much more work required to make those actually parallel. The other opportunities this opens up are allowing multiple workers for one large index cleanups and heap pass in a parallel vacuum. Do you see any other fundamental problems that need to be solved for parallel inserts? Having said that, we still have some problems to solve to make updates or deletes parallel. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com