At Fri, 15 Sep 2017 15:36:26 +0900, Amit Langote
wrote in
> Hi.
>
> On 2017/08/28 18:28, Kyotaro HORIGUCHI wrote:
> > << the following is another topic >>
> >
> BTW, in the partitioned table case, the parent is always locked first
> using an AccessExclusiveLock. There are other con
On 2017/09/15 15:36, Amit Langote wrote:
> The fact that
> parent is locked after the child and with ShareUpdateExclusiveLock instead
> of AccessExclusiveLock, we observe this race condition when SELECTing from
> the parent.
Oops, I meant "parent table is locked with AccessShareLock instead of
Acc
Hi.
On 2017/08/28 18:28, Kyotaro HORIGUCHI wrote:
> << the following is another topic >>
>
BTW, in the partitioned table case, the parent is always locked first
using an AccessExclusiveLock. There are other considerations in that case
such as needing to recreate the partition desc
At Wed, 13 Sep 2017 20:20:48 -0400, Robert Haas wrote
in
> On Mon, Jun 26, 2017 at 4:46 AM, Kyotaro HORIGUCHI
> wrote:
> > The cause is that NO INHERIT doesn't take an exlusive lock on the
> > parent. This allows expand_inherited_rtentry to add the child
> > relation into appendrel after remova
On Mon, Jun 26, 2017 at 4:46 AM, Kyotaro HORIGUCHI
wrote:
> The cause is that NO INHERIT doesn't take an exlusive lock on the
> parent. This allows expand_inherited_rtentry to add the child
> relation into appendrel after removal from the inheritance but
> still exists.
>
> I see two ways to fix t
On 2017/09/13 12:05, Simon Riggs wrote:
> On 26 June 2017 at 10:16, Amit Langote wrote:
>
>> BTW, in the partitioned table case, the parent is always locked first
>> using an AccessExclusiveLock. There are other considerations in that case
>> such as needing to recreate the partition descriptor
On 26 June 2017 at 10:16, Amit Langote wrote:
> BTW, in the partitioned table case, the parent is always locked first
> using an AccessExclusiveLock. There are other considerations in that case
> such as needing to recreate the partition descriptor upon termination of
> inheritance (both the DET
At Mon, 28 Aug 2017 18:28:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170828.182807.98097766.horiguchi.kyot...@lab.ntt.co.jp>
> I'll add this to CF2017-09.
This patch got deadly atack from the commit 30833ba. I changed
the signature of expand_single_inheritance_child in additi
Hello,
I'll add this to CF2017-09.
At Tue, 27 Jun 2017 16:27:18 +0900, Amit Langote
wrote in
<75fe42df-b1d8-89ff-596d-d9da0749e...@lab.ntt.co.jp>
> On 2017/06/26 18:44, Kyotaro HORIGUCHI wrote:
> > At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote wrote:
> >>
> >> I recall I had proposed a fix
On 2017/06/26 18:44, Kyotaro HORIGUCHI wrote:
> At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote wrote:
>>
>> I recall I had proposed a fix for the same thing some time ago [1].
>
> Wow. About 1.5 years ago and stuck? I have a concrete case where
> this harms so I'd like to fix that this time. Ho
Hello,
At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote
wrote in
<7f5fe522-f328-3c40-565f-5e1ce3745...@lab.ntt.co.jp>
> Hello,
>
> On 2017/06/26 17:46, Kyotaro HORIGUCHI wrote:
> > Hello.
> >
> > I had a case of unexpected error caused by ALTER TABLE NO
> > INHERIT.
> >
> > =# CREATE TABLE p
Hello,
On 2017/06/26 17:46, Kyotaro HORIGUCHI wrote:
> Hello.
>
> I had a case of unexpected error caused by ALTER TABLE NO
> INHERIT.
>
> =# CREATE TABLE p (a int);
> =# CREATE TABLE c1 () INHERITS (p);
>
> session A=# BEGIN;
> session A=# ALTER TABLE c1 NO INHERIT p;
>
> session B=# EXPLAIN
Hello.
I had a case of unexpected error caused by ALTER TABLE NO
INHERIT.
=# CREATE TABLE p (a int);
=# CREATE TABLE c1 () INHERITS (p);
session A=# BEGIN;
session A=# ALTER TABLE c1 NO INHERIT p;
session B=# EXPLAIN ANALYZE SELECT * FROM p;
(blocked)
session A=# COMMIT;
session B: ERROR: co
13 matches
Mail list logo
