aboutsummaryrefslogtreecommitdiff
path: root/contrib/btree_gist/btree_oid.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2014-05-14 14:55:48 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2014-05-14 14:56:08 -0400
commitb23b0f5588d2e2f15edff66e072e339a8c9616a7 (patch)
tree4f4fc7804d31955fd244a899867e14ee2ebea922 /contrib/btree_gist/btree_oid.c
parentac53295d667e7727d7b70ddf11d82c067870501f (diff)
downloadpostgresql-b23b0f5588d2e2f15edff66e072e339a8c9616a7.tar.gz
postgresql-b23b0f5588d2e2f15edff66e072e339a8c9616a7.zip
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.
Diffstat (limited to 'contrib/btree_gist/btree_oid.c')
0 files changed, 0 insertions, 0 deletions