Thank you for pointing out and comments. On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> No, that's not right. Now that you mention it, I realize that tuple >> locks can definitely cause deadlocks. Example: > > Yeah. Foreign-key-related tuple locks are another rich source of > examples. > >> ... So I don't >> think we can remove speculative insertion locks from the deadlock >> detector either. > > That scares me too. I think that relation extension can safely > be transferred to some lower-level mechanism, because what has to > be done while holding the lock is circumscribed and below the level > of database operations (which might need other locks). These other > ideas seem a lot riskier. > > (But see recent conversation where I discouraged Alvaro from holding > extension locks across BRIN summarization activity. We'll need to look > and make sure that nobody else has had creative ideas like that.) >
It seems that we should focus on transferring only relation extension locks as a first step. The page locks would also be safe but it might require some fundamental changes related to fast insertion, which is discussed on other thread[1]. Also in this case I think it's better to focus on relation extension locks so that we can optimize the lower-level lock mechanism for it. So I'll update the patch based on the comment I got from Robert before. [1] https://www.postgresql.org/message-id/CAD21AoBLUSyiYKnTYtSAbC%2BF%3DXDjiaBrOUEGK%2BzUXdQ8owfPKw%40mail.gmail.com Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
