On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: >> Then, the reason for the TRY-CATCH cluase is that I found that >> some functions called from there can throw exceptions. > > Yes, but all LWLocks should be released by normal error recovery. > It should not be necessary for this code to clean that up by hand. > If it were necessary, there would be TRY-CATCH around every single > LWLockAcquire in the backend, and we'd have an unreadable and > unmaintainable system. Please don't add a TRY-CATCH unless it's > *necessary* -- and you haven't explained why this one is.
Putting hands into the code and at the problem, I can see that dropping a subscription on a node makes it unresponsive in case of a stop. And that's just because calls to LWLockRelease are missing as in the patch attached. A try/catch problem should not be necessary. -- Michael
drop-subs-locks.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
