Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On Thu, Apr 12, 2018 at 3:59 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> Please revert the part of this commit that changed the lock level. > > Done. Thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Robert Haas wrote: > Please revert the part of this commit that changed the lock level. Done. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Robert Haas wrote: > I don't think it was a good idea to change this without a lot more > discussion, as part of another commit that really was about something > else, and after feature freeze. > Please revert the part of this commit that changed the lock level. You're right, that was too

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On Mon, Apr 2, 2018 at 3:11 PM, Alvaro Herrera wrote: > Why do we need AccessExclusiveLock on all children of a relation that we > want to scan to search for rows not satisfying the constraint? I think > it should be enough to get ShareLock, which prevents INSERT, no? I

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Thanks for the discussion. Per your suggestions, I changed the check for default partition OID to an assert instead of the 'if' condition, and removed the code that attempted vainly to verify the constraint when attaching a foreign table as a partition. And pushed. I think we're done here, so

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Added to the open items list. https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Open_Issues On Tue, Apr 3, 2018 at 2:52 PM, Amit Langote wrote: > On 2018/04/03 14:45, Kyotaro HORIGUCHI wrote: > > Hello. > > > > At Mon, 2 Apr 2018 16:11:12 -0300, Alvaro

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On 2018/04/03 14:45, Kyotaro HORIGUCHI wrote: > Hello. > > At Mon, 2 Apr 2018 16:11:12 -0300, Alvaro Herrera > wrote: >> Why do we need AccessExclusiveLock on all children of a relation that we >> want to scan to search for rows not satisfying the constraint? I think

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Hello. At Mon, 2 Apr 2018 16:11:12 -0300, Alvaro Herrera wrote in <20180402191112.wneiyj4v5upnfjst@alvherre.pgsql> > Why do we need AccessExclusiveLock on all children of a relation that we > want to scan to search for rows not satisfying the constraint? I think > it

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Why do we need AccessExclusiveLock on all children of a relation that we want to scan to search for rows not satisfying the constraint? I think it should be enough to get ShareLock, which prevents INSERT, no? I have a feeling I'm missing something here, but I don't know what, and all tests pass

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

> /* > - * Check whether default partition has a row that would fit the > partition > - * being attached. > + * Check if the default partition contains a row that would belong in > the > + * partition being attached. >*/ > - defaultPartOid = > -

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Thanks Jeevan for reviewing. On 2018/04/02 13:10, Jeevan Ladhe wrote: > Hi, > > I noticed that there were no tests covering this case causing 4dba331cb3 >> to not notice this failure in the first place. I updated your patch to >> add a few tests. Also, I revised the comment changed by your

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Hi, I noticed that there were no tests covering this case causing 4dba331cb3 > to not notice this failure in the first place. I updated your patch to > add a few tests. Also, I revised the comment changed by your patch a bit. > 1. A minor typo: +-- check that violating rows are correctly

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

On 2018/03/30 17:31, Kyotaro HORIGUCHI wrote: > At Thu, 29 Mar 2018 13:04:06 -0300, Alvaro Herrera wrote: >> Rushabh Lathia wrote: >>> On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera >>> wrote: >> Hmm, offhand I don't quite see why this error fails to be thrown. >>>

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

At Thu, 29 Mar 2018 13:04:06 -0300, Alvaro Herrera wrote in <20180329160406.ii2wgbkmlnfxtwbt@alvherre.pgsql> > Rushabh Lathia wrote: > > On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera > > wrote: > > > > Hmm, offhand I don't quite see why this

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Rushabh Lathia wrote: > On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera > 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

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Rushabh Lathia wrote: > CREATE TABLE foo (a INT, b INT, c VARCHAR) PARTITION BY LIST(a); > CREATE TABLE foo_p1 PARTITION OF foo FOR VALUES IN (1,2); > CREATE TABLE foo_p2 PARTITION OF foo FOR VALUES IN (3,4); > INSERT INTO foo select i,i,i from generate_series(1,4)i; > > CREATE TABLE foo_d (like

Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Hi, Consider the below test: CREATE TABLE foo (a INT, b INT, c VARCHAR) PARTITION BY LIST(a); CREATE TABLE foo_p1 PARTITION OF foo FOR VALUES IN (1,2); CREATE TABLE foo_p2 PARTITION OF foo FOR VALUES IN (3,4); INSERT INTO foo select i,i,i from generate_series(1,4)i; CREATE TABLE foo_d (like