Obtain stronger lock while commiting shared relcache.
authorTatsuo Ishii <ishii@sraoss.co.jp>
Mon, 30 Jan 2023 02:02:22 +0000 (11:02 +0900)
committerTatsuo Ishii <ishii@sraoss.co.jp>
Mon, 30 Jan 2023 02:02:22 +0000 (11:02 +0900)
commit5151a24f3f1fc60b0dd8cb58b149e0a5671b0034
tree3349c69d1844f724d2a340e39e60e6aa8f031244
parentc0415519cbfeb24f3ca1d45bcc85b3e0ab7e4447
Obtain stronger lock while commiting shared relcache.

Previously pool_search_relcache() obtained only shared lock, which is
not safe enough to call pool_catalog_commit_cache() because it
registers new cache entry. Unfortunately our locking system does not
allow to escalate a shared lock to an exclusive lock. So we release
the shared lock then acquire the exclusive lock before calling
pool_catalog_commit_cache(). There's a window between them and we may
end up with an effort to register duplicate cache entry. But
underlying infrastructure of the query system will reject it and
should be safe.

Back-patch through 4.4 where the shared locking of the query cache
system was introduced.
src/utils/pool_relcache.c