| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "yotsunaga(dot)naoki(at)fujitsu(dot)com" <yotsunaga(dot)naoki(at)fujitsu(dot)com> |
| Cc: | Pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Lock acquisition for partition table when setting generic plan |
| Date: | 2020-01-15 15:09:10 |
| Message-ID: | 2183.1579100950@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"yotsunaga(dot)naoki(at)fujitsu(dot)com" <yotsunaga(dot)naoki(at)fujitsu(dot)com> writes:
> I did the following.
> Even though I accessed one partition table(test2 table), I also acquired locks on other partition tables(test1 table).
> I expected to acquire locks on the parent table(test table) and the partition table to access(test2 table).
> Why does this happen?
You specified a generic plan:
> postgres=# set plan_cache_mode = force_generic_plan ;
so you are not going to get any plan-time optimization based on knowing
the id parameter. Therefore the plan must include sub-plan nodes for
every child table, so executing it requires locking all those tables
to make sure their schemas haven't changed.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kasun Kulathunga | 2020-01-15 16:19:26 | Upgrading from 9.6 to 12 |
| Previous Message | Laurenz Albe | 2020-01-15 06:34:22 | Re: Lock leaking out of Transaction? |