Code review for recent changes in relcache.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 14 May 2014 18:55:50 +0000 (14:55 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 14 May 2014 18:55:50 +0000 (14:55 -0400)
commite7a9020939c9f09eddf6cf2f5477f82a1efcbf09
tree9e77d1db4cc613a5778c98822fbd0e767b09dc05
parentd5b912c905efd531a6228d08c98cd92d49cdd94c
Code review for recent changes in relcache.c.

rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr
and rd_idattr should be managed like rd_indexattr.  Omissions in this area
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be
leaked during any relcache flush, resulting in a slow but permanent leak in
CacheMemoryContext.  There was also a tiny probability of relcache entry
corruption if we ran out of memory at just the wrong point in
RelationGetIndexAttrBitmap.  Otherwise, the fields were not zeroed where
expected, which would not bother the code any AFAICS but could greatly
confuse anyone examining the relcache entry while debugging.

Also, create an API function RelationGetReplicaIndex rather than letting
non-relcache code be intimate with the mechanisms underlying caching of
that value (we won't even mention the memory leak there).

Also, fix a relcache flush hazard identified by Andres Freund:
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid
across index_open.

The aspects of this involving rd_keyattr date back to 9.3, so back-patch
those changes.
src/backend/utils/cache/relcache.c