Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Дата
Msg-id CA+HiwqG4hQEmDTpD5NM0Da4+UeVmVx7ZrB16KyRbjT4offzgUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY  (Hao Wu <hawu@vmware.com>)
Список pgsql-hackers
Hi Hao,

On Wed, Sep 2, 2020 at 5:25 PM Hao Wu <hawu@vmware.com> wrote:
>
> Not related to DETACH PARTITION, but I found a bug in ATTACH PARTITION.
> Here are the steps to reproduce the issue:
>
> create table tpart(i int, j int) partition by range(i);
> create table tpart_1(like tpart);
> create table tpart_2(like tpart);
> create table tpart_default(like tpart);alter table tpart attach partition tpart_1 for values from(0) to (100);
> alter table tpart attach partition tpart_default default;insert into tpart_2 values(110,110),(120,120),(150,150);1:
begin;
> 1: alter table tpart attach partition tpart_2 for values from(100) to (200);
> 2: begin;
> -- insert will be blocked by ALTER TABLE ATTACH PARTITION
> 2: insert into tpart values (110,110),(120,120),(150,150);
> 1: end;
> 2: select * from tpart_default;
> 2: end;
>
>
> After that the partition tpart_default contains (110,110),(120,120),(150,150)
> inserted in session 2, which obviously violates the partition constraint.

Thanks for the report.  That looks like a bug.

I have started another thread to discuss this bug and a patch to fix
it to keep the discussion here focused on the new feature.

Subject: default partition and concurrent attach partition
https://www.postgresql.org/message-id/CA%2BHiwqFqBmcSSap4sFnCBUEL_VfOMmEKaQ3gwUhyfa4c7J_-nA%40mail.gmail.com

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: default partition and concurrent attach partition
Следующее
От: Amit Langote
Дата:
Сообщение: Re: default partition and concurrent attach partition