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, 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.
--
Robert Haas
EDB: http://www.enterprisedb.com