pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Ildar Musin <i.musin@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Declarative partitioning
Date: Tue, 17 May 2016 13:22:42 -0400
Message-ID: <1404.1463505762@sss.pgh.pa.us> (raw)
In-Reply-To: <573ACEB2.1090705@lab.ntt.co.jp>
References: <55D3093C.5010800@lab.ntt.co.jp>
	<56DE2D4B.1040001@lab.ntt.co.jp>
	<CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com>
	<56DF74F0.7060404@lab.ntt.co.jp>
	<CAPpHfdut34uqoY1vKgvBhsGZqhR6Nky=_Dxn0un57G_M2CvLTA@mail.gmail.com>
	<CA+HiwqFFH10_ku6z_Ps=H7=pR5cWJk9Bdr9nE08+3F53yTEr9A@mail.gmail.com>
	<CAPpHfdu0mGbt9T2Jx04OKJfJQ0zW55BFqmisinRYWd2OaowRWQ@mail.gmail.com>
	<CA+TgmoaoZRqk2dr3xonta3o4omKuO4V4niVC2DKKo9VpdMc_zQ@mail.gmail.com>
	<56F0AC96.2010303@lab.ntt.co.jp>
	<CAFjFpReZ2nmpfOA2uGdgVp3ivWC13VDFYOQ7rs5LFeqo_Zm4vA@mail.gmail.com>
	<57106F9E.3000309@lab.ntt.co.jp>
	<57163954.2020701@postgrespro.ru>
	<CAPpHfdtH4rhckHzkqGhGP8O7aejj=J7_qJRA3dTu+iAUpuzPgg@mail.gmail.com>
	<CA+HiwqEMQ2EZ0GKBjg2hHT1uP-NRodtodc2JjN1vd0xp_BzTCg@mail.gmail.com>
	<571759D8.7030205@lab.ntt.co.jp>
	<57179653.30905@postgrespro.ru>
	<CA+HiwqF=0v6afwGj=Fc3gBF94Wp65naJUiDt6sFQiNXvtsFXSg@mail.gmail.com>
	<57183572.8020900@lab.ntt.co.jp>
	<5739C742.80504@postgrespro.ru>
	<573ACEB2.1090705@lab.ntt.c! o.jp>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> 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



view thread (161+ messages)  latest in thread

Message-ID: <1404.1463505762@sss.pgh.pa.us>
Permalink:  ../1404.1463505762@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1404.1463505762@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, Langote_Amit_f8@lab.ntt.co.jp, i.musin@postgrespro.ru
  Subject: Re: Declarative partitioning
  In-Reply-To: <1404.1463505762@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox