Thank you for pointing out and comments.
On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
