| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Shinoda, Noriyoshi" <noriyoshi(dot)shinoda(at)hpe(dot)com> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: unique indexes on partitioned tables |
| Date: | 2018-03-12 22:50:40 |
| Message-ID: | 20180312225040.qvtfmf5i45x5nwrk@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Shinoda, Noriyoshi wrote:
Hi,
> I tried this feature with the latest snapshot. When I executed the
> following SQL statement, multiple primary keys were created on the
> partition.
> Is this the intended behavior?
It turns out that the error check for duplicate PKs is only invoked if
you tell this code that it's being invoked by ALTER TABLE, and my
original patch wasn't. I changed it and now everything seems to behave
as expected.
I added a test case pretty much like yours, which now works correctly.
I also added another one where the bogus PK is two levels down rather
than one. This is because I had originally developed a different fix --
which fixed the problem for your test case, until I realized that since
this code is recursive, we could cause trouble at a distance.
Thanks for reporting the problem
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2018-03-12 22:57:45 | Re: Fix error in ECPG while connection handling |
| Previous Message | Tom Lane | 2018-03-12 22:44:32 | Re: Additional Statistics Hooks |