Horton

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Rushabh Lathia <rushabh.lathia@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-29T16:04:06Z
Lists: pgsql-hackers 
Rushabh Lathia wrote:
> On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera <alvherre@alvh.no-ip.org>
> wrote:

> > Hmm, offhand I don't quite see why this error fails to be thrown.
>
> ATTACH PARTITION should throw an error, because partition table "foo"
> already have two partition with key values (1, 2,3 4). And table "foo_d"
> which we are attaching here has :

Oh, I understand how it's supposed to work.  I was just saying I don't
understand how this bug occurs.  Is it because we fail to determine the
correct partition constraint for the default partition in time for its
verification scan?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Revert lowering of lock level for ATTACH PARTITION

  2. Fix ALTER TABLE .. ATTACH PARTITION ... DEFAULT

  3. Fix relcache handling of the 'default' partition

  4. Fix CommandCounterIncrement in partition-related DDL

  5. Fix lock upgrade hazard in ATExecAttachPartition.