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
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
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 hasty.
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 have
> a feeling I'm miss
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 ma
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 Herrera <
> alvhe...@alvh.no-ip.or
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
>> it should be enough to g
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 should be enough to get Sha
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 w
> /*
> - * 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 =
> - g
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 patc
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 repor
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.
>>>
>>> ATTACH PARTITION shoul
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 error fails to be thrown.
> >
> > ATTACH PARTITION
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 (1, 2,3 4). And table "foo_
On Thu, Mar 29, 2018 at 7:46 PM, Alvaro Herrera
wrote:
> 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 sel
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
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 foo)
18 matches
Mail list logo