From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic plans and "initial" pruning |
Date: | 2022-01-19 11:16:44 |
Message-ID: | CANbhV-H+pk_59fB+JJAfOzKBSpvzcvFx2YTKakx=woCQucRCHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 19 Jan 2022 at 08:31, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > Maybe force all DDL, or just DDL that would cause safety issues, to
> > update a hierarchy version number, so queries can tell whether they
> > need to replan. Don't know, just looking for an O(1) solution.
>
> Yeah, it would be great if it would suffice to take a single lock on
> the partitioned table mentioned in the query, rather than on all
> elements of the partition tree added to the plan. AFAICS, ways to get
> that are 1) Prevent modifying non-root partition tree elements,
Can we reuse the concept of Strong/Weak locking here?
When a DDL request is in progress (for that partitioned table), take
all required locks for safety. When a DDL request is not in progress,
take minimal locks knowing it is safe.
We can take a single PartitionTreeModificationLock, nowait to prove
that we do not need all locks. DDL would request the lock in exclusive
mode. (Other mechanisms possible).
--
Simon Riggs http://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Heiss | 2022-01-19 12:11:05 | Re: [PATCH] Add reloption for views to enable RLS |
Previous Message | Amit Langote | 2022-01-19 10:52:57 | Re: a misbehavior of partition row movement (?) |