Re: BUG #17339: Assert failed on attempt to detach a sequence concurrently

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17339: Assert failed on attempt to detach a sequence concurrently
Date: 2021-12-20 20:57:47
Message-ID: c19d2596-c525-1405-fe14-73bed9af6bde@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On 20.12.21 13:38, Michael Paquier wrote:
> On Sun, Dec 19, 2021 at 06:00:02AM +0000, PG Bug reporting form wrote:
>> CREATE SEQUENCE seq;
>> CREATE TABLE range_parted(a int) PARTITION BY RANGE(a);
>> ALTER TABLE range_parted DETACH PARTITION seq CONCURRENTLY;
>
> The same error happens additionally for views or materialized views.
> Looking at the code, I think that we should just apply
> ATSimplePermissions() on (ATT_TABLE | ATT_FOREIGN_TABLE) when
> executing the detach command to check for the supported relkinds.
> That would make the logic consistent with the attach code path that
> does the same check on the partition attached, while generating an
> error message already generic enough for this purpose.
>
> Attached is a patch, with some regression tests.

Is it possible for child tables in partitioned tables to have different
ownerships? Then this change would introduce a new failure mode.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-12-21 00:30:42 Re: BUG #17339: Assert failed on attempt to detach a sequence concurrently
Previous Message Michael Paquier 2021-12-20 12:38:03 Re: BUG #17339: Assert failed on attempt to detach a sequence concurrently