]> granicus.if.org Git - postgresql/commit
Fix relcache reload mechanism to be more robust in the face of errors
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Jan 2010 18:12:40 +0000 (18:12 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Jan 2010 18:12:40 +0000 (18:12 +0000)
commit483b17119a098e282968d2d2050345b97643599c
tree55ca00e8b2430585aa21c344aba10995777cc66b
parent26098d8f8650d3ee667b75de54c6977b7ef021b3
Fix relcache reload mechanism to be more robust in the face of errors
occurring during a reload, such as query-cancel.  Instead of zeroing out
an existing relcache entry and rebuilding it in place, build a new relcache
entry, then swap its contents with the old one, then free the new entry.
This avoids problems with code believing that a previously obtained pointer
to a cache entry must still reference a valid entry, as seen in recent
failures on buildfarm member jaguar.  (jaguar is using CLOBBER_CACHE_ALWAYS
which raises the probability of failure substantially, but the problem
could occur in the field without that.)  The previous design was okay
when it was made, but subtransactions and the ResourceOwner mechanism
make it unsafe now.

Also, make more use of the already existing rd_isvalid flag, so that we
remember that the entry requires rebuilding even if the first attempt fails.

Back-patch as far as 8.2.  Prior versions have enough issues around relcache
reload anyway (due to inadequate locking) that fixing this one doesn't seem
worthwhile.
src/backend/utils/cache/relcache.c