On 2018/06/13 23:39, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Seems reasonable. Really, I think we should look for a way to hang
>> onto the relation at the point where it's originally opened and locked
>> instead of reopening it here. But that's probably more invasive than
>> we can really justify right at the moment, and I think this is a step
>> in a good direction.
>
> The existing coding there makes me itch a bit, because there's only a
> rather fragile line of reasoning justifying the assumption that there is a
> pre-existing lock at all. So I'd be in favor of what you suggest just to
> get rid of the "open(NoLock)" hazard. But I agree that it'd be rather
> invasive and right now is probably not the time for it.
I had sent a patch to try to get rid of the open(NoLock) there a couple of
months ago [1]. The idea was to both lock and open the relation in
ExecNonLeafAppendTables, which is the first time all partitioned tables in
a given Append node are locked for execution. Also, the patch makes it a
responsibility of ExecEndAppend to release the relcache pins, so the
recently added ExecDestroyPartitionPruneState would not be needed.
Attached is a rebased version of that patch if there is interest in it.
Thanks,
Amit
[1]
https://www.postgresql.org/message-id/0b361a22-f995-e15c-a385-6d1b72dd0d13%40lab.ntt.co.jp