On 2016/05/18 2:22, Tom Lane wrote: > Amit Langote <langote_amit...@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.
I see. Thanks for clarifying. > 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. It seems that tuple descriptor is reference-counted; however trigger data is copied. The former seems to have been done on performance grounds (I found 06e10abc). So for a performance-sensitive relcache data structure, refcounting is the way to go (although done quite rarely)? In this particular case, it is a "partition descriptor" that could get big for a partitioned table with partitions in hundreds or thousands. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
