| From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
|---|---|
| To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | RE: [bug?] Missed parallel safety checks, and wrong parallel safety |
| Date: | 2021-06-24 04:19:47 |
| Message-ID: | OS0PR01MB5716E0591AE7C43BBC51D77494079@OS0PR01MB5716.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thursday, June 24, 2021 11:44 AM Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:
> Hi,
> How about walking the partition hierarchy bottom up, recording the parents but not taking the locks.
> Once top-most parent is found, take the locks in reverse order (top down) ?
IMO, When we directly INSERT INTO a partition, postgres already lock the partition
as the target table before execution which means we cannot postpone the lock
on partition to find the parent table.
Best regards,
houzj
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-06-24 04:25:15 | Re: Decoding speculative insert with toast leaks memory |
| Previous Message | Greg Nancarrow | 2021-06-24 03:55:14 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |