On Mon, Nov 6, 2017 at 4:42 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: >>> I suggest that a good thing to do more or less immediately, regardless >>> of when this patch ends up being ready, would be to insert an >>> insertion that LockAcquire() is never called while holding a lock of >>> one of these types. If that assertion ever fails, then the whole >>> theory that these lock types don't need deadlock detection is wrong, >>> and we'd like to find out about that sooner or later. >> >> I understood. I'll check that first. > > I've checked whether LockAcquire is called while holding a lock of one > of four types: LOCKTAG_RELATION_EXTENSION, LOCKTAG_PAGE, > LOCKTAG_TUPLE, and LOCKTAG_SPECULATIVE_TOKEN. To summary, I think that > we cannot move these four lock types together out of heavy-weight > lock, but can move only the relation extension lock with tricks. > > Here is detail of the survey.
Thanks for these details, but I'm not sure I fully understand. > * LOCKTAG_RELATION_EXTENSION > There is a path that LockRelationForExtension() could be called while > holding another relation extension lock. In brin_getinsertbuffer(), we > acquire a relation extension lock for a index relation and could > initialize a new buffer (brin_initailize_empty_new_buffer()). During > initializing a new buffer, we call RecordPageWithFreeSpace() which > eventually can call fsm_readbuf(rel, addr, true) where the third > argument is "extend". We can process this problem by having the list > (or local hash) of acquired locks and skip acquiring the lock if > already had. For other call paths calling LockRelationForExtension, I > don't see any problem. Does calling fsm_readbuf(rel,addr,true) take some heavyweight lock? Basically, what matters here in the end is whether we can articulate a deadlock-proof rule around the order in which these locks are acquired. The simplest such rule would be "you can only acquire one lock of any of these types at a time, and you can't subsequently acquire a heavyweight lock". But a more complicated rule would be OK too, e.g. "you can acquire as many heavyweight locks as you want, and after that you can optionally acquire one page, tuple, or speculative token lock, and after that you can acquire a relation extension lock". The latter rule, although more complex, is still deadlock-proof, because the heavyweight locks still use the deadlock detector, and the rest has a consistent order of lock acquisition that precludes one backend taking A then B while another backend takes B then A. I'm not entirely clear whether your survey leads us to a place where we can articulate such a deadlock-proof rule. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers