Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2ijC-0005uY-W2 for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2016 17:24:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b2ijC-000480-IS for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2016 17:24:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b2ihr-0002dA-S4 for pgsql-hackers@postgresql.org; Tue, 17 May 2016 17:22:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b2ihp-0002H5-8I for pgsql-hackers@postgresql.org; Tue, 17 May 2016 17:22:54 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u4HHMgIF029646; Tue, 17 May 2016 13:22:45 -0400 From: Tom Lane To: Amit Langote cc: Ildar Musin , pgsql-hackers@postgresql.org Subject: Re: Declarative partitioning In-reply-to: <573ACEB2.1090705@lab.ntt.co.jp> References: <55D3093C.5010800@lab.ntt.co.jp> <56DE2D4B.1040001@lab.ntt.co.jp> <56DF74F0.7060404@lab.ntt.co.jp> <56F0AC96.2010303@lab.ntt.co.jp> <57106F9E.3000309@lab.ntt.co.jp> <57163954.2020701@postgrespro.ru> <571759D8.7030205@lab.ntt.co.jp> <57179653.30905@postgrespro.ru> <57183572.8020900@lab.ntt.co.jp> <5739C742.80504@postgrespro.ru> <573ACEB2.1090705@lab.ntt.c! o.jp> Comments: In-reply-to Amit Langote message dated "Tue, 17 May 2016 16:56:34 +0900" Date: Tue, 17 May 2016 13:22:42 -0400 Message-ID: <1404.1463505762@sss.pgh.pa.us> X-Pg-Spam-Score: -3.3 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Amit Langote writes: > On 2016/05/16 22:12, Ildar Musin wrote: >> Could you please tell is >> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE >> query? > Hmm, I think invalidation would not occur mid-query since it would have > acquired a lock on the table. This is incorrect: invalidation can occur anyway (for example, if autoanalyze updates the relation's statistics). If you are holding a lock, you can expect that the relation's schema will not change more than your lock would allow --- but a cache flush and rebuild could happen underneath you, so keeping a pointer to any subsidiary relcache data structure is very dangerous. The two ways that we've dealt with this type of hazard are to copy data out of the relcache before using it; or to give the relcache the responsibility of not moving a particular portion of data if it did not change. From memory, the latter applies to the tuple descriptor and trigger data, but we've done most other things the first way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers