From: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Date: | 2022-05-31 20:22:32 |
Message-ID: | 87b560e3-c5fa-ab78-4109-20f8aa24f5cc@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I didn't read the patch, but what lock level does that place on the
> partitioned table? Anything more than ACCESS SHARE?
Current patch locks a partitioned table with ACCESS EXCLUSIVE lock.
Unfortunately only this lock guarantees that other session can not work
with partitions that are splitting or merging.
I want add CONCURRENTLY mode in future. With this mode partitioned table
during SPLIT/MERGE operation will be locked with SHARE UPDATE EXCLUSIVE
(as ATTACH/DETACH PARTITION commands in CONCURRENTLY mode).
But in this case queries from other sessions that want to work with
partitions that are splitting/merging at this time should receive an
error (like "Partition data is moving. Repeat the operation later")
because old partitions will be deleted at the end of SPLIT/MERGE operation.
I hope exists a better solution, but I don't know it now...
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-05-31 20:32:07 | Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) |
Previous Message | David G. Johnston | 2022-05-31 20:12:23 | Re: Assorted small doc patches |