Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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: > >> >

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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.

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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 > >

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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

[HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

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: