=?UTF-8?Q?Martin_Lund_Ask=C3=B8e?= <martinlundaskoe@gmail.com> writes:
> It feels like a bug to me, that the relcache entry update leaves my
> transaction with an access shared lock.
It is not a bug. The fact that the uncommitted insert takes a lock
preventing any DDL changing the partition structure is actually an
essential property, because otherwise such DDL could perhaps change
which partition the inserted row should have gone into. The DDL
command would then be responsible for moving rows appropriately ...
but it can't see an uncommitted row from another session, so it
would fail to move it. Result: corrupted data.
It might be possible to draw some lines around which sorts of
partition-changing DDL could result in that sort of change, allowing
more fine-grained locking. But we don't have any mechanism for that
right now, and I'm not really sure that it'd be cost-effective to
draw finer distinctions.
regards, tom lane