Thread: update ALTER TABLE with ATTACH PARTITION lock mode
commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock) updates ddl.sgml but not alter_table.sgml, which only says: https://www.postgresql.org/docs/12/release-12.html |An ACCESS EXCLUSIVE lock is held unless explicitly noted. Find attached patch, which also improve language in several related places. "Without such a constraint": SUCH could refer to either of the constraints.. "because it is no longer necessary.": In our use case, we prefer to keep the redundant constraint, to avoid having to add it back if we detach/reattach again in the future..
Attachment
On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote: > commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock) > updates ddl.sgml but not alter_table.sgml, which only says: > > https://www.postgresql.org/docs/12/release-12.html > |An ACCESS EXCLUSIVE lock is held unless explicitly noted. + <para> + Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> + lock on the partitioned table, in addition to an + <literal>ACCESS EXCLUSIVE</literal> lock on the partition. + </para> Updating the docs of ALTER TABLE sounds like a good idea. This sentence looks fine to me. Perhaps others have suggestions? > Find attached patch, which also improve language in several related places. Not sure that these are actually improvements. -- Michael
Attachment
On 2019-Oct-28, Michael Paquier wrote: > On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote: > > commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock) > > updates ddl.sgml but not alter_table.sgml, which only says: > > > > https://www.postgresql.org/docs/12/release-12.html > > |An ACCESS EXCLUSIVE lock is held unless explicitly noted. > > + <para> > + Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> > + lock on the partitioned table, in addition to an > + <literal>ACCESS EXCLUSIVE</literal> lock on the partition. > + </para> > Updating the docs of ALTER TABLE sounds like a good idea. This > sentence looks fine to me. Perhaps others have suggestions? Doesn't the command also acquire a lock on the default partition if there is one? It sounds worth noting. > > Find attached patch, which also improve language in several related places. > > Not sure that these are actually improvements. I think some of them (most?) are clear improvements. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Oct 28, 2019 at 12:06:44PM -0300, Alvaro Herrera wrote: > On 2019-Oct-28, Michael Paquier wrote: > > > On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote: > > > commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock) > > > updates ddl.sgml but not alter_table.sgml, which only says: > > > > > > https://www.postgresql.org/docs/12/release-12.html > > > |An ACCESS EXCLUSIVE lock is held unless explicitly noted. > > > > + <para> > > + Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> > > + lock on the partitioned table, in addition to an > > + <literal>ACCESS EXCLUSIVE</literal> lock on the partition. > > + </para> > > Updating the docs of ALTER TABLE sounds like a good idea. This > > sentence looks fine to me. Perhaps others have suggestions? > > Doesn't the command also acquire a lock on the default partition if > there is one? It sounds worth noting. I suppose it should something other than partition(ed), since partitions can be partitioned, too... Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> lock on the parent table, in addition to <literal>ACCESS EXCLUSIVE</literal> locks on the child table and the <literal>DEFAULT</literal> partition (if any). Thanks, Justin
Hello, On Tue, Oct 29, 2019 at 12:13 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > On 2019-Oct-28, Michael Paquier wrote: > > On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote: > > > commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock) > > > updates ddl.sgml but not alter_table.sgml, which only says: > > > > > > https://www.postgresql.org/docs/12/release-12.html > > > |An ACCESS EXCLUSIVE lock is held unless explicitly noted. > > > > + <para> > > + Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> > > + lock on the partitioned table, in addition to an > > + <literal>ACCESS EXCLUSIVE</literal> lock on the partition. > > + </para> > > Updating the docs of ALTER TABLE sounds like a good idea. This > > sentence looks fine to me. Perhaps others have suggestions? > > Doesn't the command also acquire a lock on the default partition if > there is one? It sounds worth noting. > > > > Find attached patch, which also improve language in several related places. > > > > Not sure that these are actually improvements. > > I think some of them (most?) are clear improvements. As someone who has written some of those lines, I agree that Justin's tweaks make them more readable, so +1 to apply 0002 patch too. Thanks, Amit
On Mon, Oct 28, 2019 at 10:56:33PM -0500, Justin Pryzby wrote: > I suppose it should something other than partition(ed), since partitions can be > partitioned, too... > > Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> > lock on the parent table, in addition to > <literal>ACCESS EXCLUSIVE</literal> locks on the child table and the > <literal>DEFAULT</literal> partition (if any). In this context, "on the child table" sounds a bit confusing? Would it make more sense to say the "on the table to be attached" instead? -- Michael
Attachment
On Thu, Oct 31, 2019 at 06:07:34PM +0900, Michael Paquier wrote: > On Mon, Oct 28, 2019 at 10:56:33PM -0500, Justin Pryzby wrote: > > I suppose it should something other than partition(ed), since partitions can be > > partitioned, too... > > > > Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> > > lock on the parent table, in addition to > > <literal>ACCESS EXCLUSIVE</literal> locks on the child table and the > > <literal>DEFAULT</literal> partition (if any). > > In this context, "on the child table" sounds a bit confusing? Would > it make more sense to say the "on the table to be attached" instead? I guess you mean because it's not a child until after the ALTER. Yes, that makes sense. Thanks, Justin
On Fri, Nov 01, 2019 at 08:59:48AM -0500, Justin Pryzby wrote: > I guess you mean because it's not a child until after the ALTER. Yes, that > makes sense. Yes, perhaps you have another idea than mine on how to shape this sentence? -- Michael
Attachment
On Fri, Nov 01, 2019 at 11:01:22PM +0900, Michael Paquier wrote:
> On Fri, Nov 01, 2019 at 08:59:48AM -0500, Justin Pryzby wrote:
> > I guess you mean because it's not a child until after the ALTER. Yes, that
> > makes sense.
>
> Yes, perhaps you have another idea than mine on how to shape this
> sentence?
I can't think of anything better.
Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> lock
on the parent table, in addition to <literal>ACCESS EXCLUSIVE</literal> locks
on the table to be attached and the <literal>DEFAULT</literal> partition (if
any).
Justin
On Fri, Nov 01, 2019 at 11:58:43AM -0500, Justin Pryzby wrote:
> Attaching a partition acquires a <literal>SHARE UPDATE EXCLUSIVE</literal> lock
> on the parent table, in addition to <literal>ACCESS EXCLUSIVE</literal> locks
> on the table to be attached and the <literal>DEFAULT</literal> partition (if
> any).
Sounds fine. So gathering everything I get the attached. Any
thoughts from others?
--
Michael
Attachment
On Sat, Nov 02, 2019 at 05:19:11PM +0900, Michael Paquier wrote: > Sounds fine. So gathering everything I get the attached. Any > thoughts from others? Committed after splitting the changes in two as originally proposed. -- Michael