|From:||Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thank you for pointing out and comments.
On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
>> ... 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. 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.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
|Next Message||Michael Paquier||2017-11-14 07:44:53||Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM|
|Previous Message||David Rowley||2017-11-14 07:04:03||Re: [HACKERS] UPDATE of partition key|