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 по дате отправления: