On Tue, Mar 30, 2021 at 12:59 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Mar 25, 2021 at 11:59 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > But won't some form of lock is required for each rel entry in the hash
> > table as well for the same duration as is required for rel? Because
> > otherwise, while we are processing the statement or other relations in
> > the query, something parallel-unsafe could be attached to that
> > corresponding rel entry in the hash table. And, I feel probably some
> > concurrency bottleneck might happen because DDL/DML needs to access
> > this table at the same time.
>
> Hmm, yeah. I hadn't thought of that, but you're right: it's not good
> enough to determine that there's no problem at the time we start the
> query, because somebody could create a problem for a partition we
> haven't yet locked before we get around to locking it. This is
> something that really deserves a separate discussion rather than being
> buried on a thread on -committers with a bunch of other topics,
>
Agreed, we will summarize all the discussion and ideas by either
starting a new thread (s) or on the existing thread on hackers.
Sometime back, I have started a thread [1] with an intention to just
discuss this part of the puzzle but at that time it didn't get as much
attention as was required but I am hoping this time the situation
might improve.
> but in
> my opinion we probably shouldn't choose to handle this by adding more
> locking. The need to lock everything all the time any time we do
> anything is part of what sucks in this whole area, and we don't want
> to just keep propagating that. I don't know whether it would be OK to
> just document that if you concurrently add parallel-unsafe stuff to a
> table which is a partition while parallel inserts are going on, you
> might cause the insert to error out, but I don't think it's a
> completely crazy idea.
>
Yeah, this idea has merit and to some extent, the same is true for
what Tom, Andres, or Tsunakawa-San is proposing to keep a flag in
pg_class in someway and or have a declarative syntax for
parallel-safety for relations. Doing things on such lines might take
the complexity of locking partitions and maybe users also don't mind
if they occasionally get an error due to concurrently adding a
parallel-unsafe clause on one of the relations. I guess we can
mitigate the user's concerns to some degree by providing a function
like is_dml_rel_parallel_safe(relid/relname) where she can check all
global properties of relation and report whether it is safe or not to
perform dml and additionally we can report the unsafe property if it
is unsafe.
[1] - https://www.postgresql.org/message-id/CAA4eK1K-cW7svLC2D7DHoGHxdAdg3P37BLgebqBOC2ZLc9a6QQ%40mail.gmail.com
--
With Regards,
Amit Kapila.