Robert Haas 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
On Wed, Nov 8, 2017 at 9:40 AM, Masahiko Sawada wrote:
> Speaking of the acquiring these four lock types and heavy weight lock,
> there obviously is a call path to acquire any of four lock types while
> holding a heavy weight lock. In reverse, there also is a call path
>
On Wed, Nov 8, 2017 at 5:41 AM, Robert Haas wrote:
> On Mon, Nov 6, 2017 at 4:42 AM, Masahiko Sawada 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
On Mon, Nov 6, 2017 at 4:42 AM, Masahiko Sawada 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
>>>
On Mon, Oct 30, 2017 at 3:17 PM, Masahiko Sawada wrote:
> On Fri, Oct 27, 2017 at 12:03 AM, Robert Haas wrote:
>> On Thu, Oct 26, 2017 at 12:36 PM, Masahiko Sawada
>> wrote:
>>> Since the previous patch conflicts with current
On Fri, Oct 27, 2017 at 12:03 AM, Robert Haas wrote:
> On Thu, Oct 26, 2017 at 12:36 PM, Masahiko Sawada
> wrote:
>> Since the previous patch conflicts with current HEAD, I attached the
>> updated patch for next CF.
>
> I think we should back up
On Thu, Oct 26, 2017 at 12:36 PM, Masahiko Sawada wrote:
> Since the previous patch conflicts with current HEAD, I attached the
> updated patch for next CF.
I think we should back up here and ask ourselves a couple of questions:
1. What are we trying to accomplish here?
On Fri, Sep 8, 2017 at 4:32 AM, Masahiko Sawada wrote:
> On Fri, Sep 8, 2017 at 7:24 AM, Thomas Munro
> wrote:
>> On Wed, Aug 16, 2017 at 2:13 PM, Masahiko Sawada
>> wrote:
>>> The previous patch conflicts with
On Fri, Sep 8, 2017 at 7:24 AM, Thomas Munro
wrote:
> On Wed, Aug 16, 2017 at 2:13 PM, Masahiko Sawada
> wrote:
>> The previous patch conflicts with current HEAD, I rebased the patch to
>> current HEAD.
>
> Hi Masahiko-san,
>
> FYI this
On Fri, Sep 8, 2017 at 8:25 AM, Thomas Munro
wrote:
> On Fri, Sep 8, 2017 at 10:24 AM, Thomas Munro
> wrote:
>> On Wed, Aug 16, 2017 at 2:13 PM, Masahiko Sawada
>> wrote:
>>> The previous patch conflicts with
On Fri, Sep 8, 2017 at 10:24 AM, Thomas Munro
wrote:
> On Wed, Aug 16, 2017 at 2:13 PM, Masahiko Sawada
> wrote:
>> The previous patch conflicts with current HEAD, I rebased the patch to
>> current HEAD.
>
> Hi Masahiko-san,
Hi Sawada-san,
On Wed, Aug 16, 2017 at 2:13 PM, Masahiko Sawada wrote:
> The previous patch conflicts with current HEAD, I rebased the patch to
> current HEAD.
Hi Masahiko-san,
FYI this doesn't build anymore. I think it's just because the wait
event enumerators were re-alphabetised in
On Thu, Jun 22, 2017 at 12:03 AM, Masahiko Sawada wrote:
> On Fri, May 19, 2017 at 11:12 AM, Masahiko Sawada
> wrote:
>> On Wed, May 17, 2017 at 1:30 AM, Robert Haas wrote:
>>> On Sat, May 13, 2017 at 7:27 AM, Amit Kapila
On Fri, May 19, 2017 at 11:12 AM, Masahiko Sawada wrote:
> On Wed, May 17, 2017 at 1:30 AM, Robert Haas wrote:
>> On Sat, May 13, 2017 at 7:27 AM, Amit Kapila wrote:
>>> On Fri, May 12, 2017 at 9:14 AM, Tom Lane
On Wed, May 17, 2017 at 1:30 AM, Robert Haas wrote:
> On Sat, May 13, 2017 at 7:27 AM, Amit Kapila wrote:
>> On Fri, May 12, 2017 at 9:14 AM, Tom Lane wrote:
>>> Robert Haas writes:
On Wed, May 10,
On Sat, May 13, 2017 at 7:27 AM, Amit Kapila wrote:
> On Fri, May 12, 2017 at 9:14 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
>>> wrote:
... I'd
On Sat, May 13, 2017 at 8:19 PM, Amit Kapila wrote:
> On Thu, May 11, 2017 at 6:09 AM, Masahiko Sawada
> wrote:
>> This work would be helpful not only for existing workload but also
>> future works like some parallel utility commands, which is
On Fri, May 12, 2017 at 9:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
>> wrote:
>>> ... I'd like to propose to change relation
>>> extension lock management so that it works
On Thu, May 11, 2017 at 6:09 AM, Masahiko Sawada wrote:
> This work would be helpful not only for existing workload but also
> future works like some parallel utility commands, which is discussed
> on other threads[1]. At least for parallel vacuum, this feature helps
> to
Robert Haas writes:
> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
> wrote:
>> ... I'd like to propose to change relation
>> extension lock management so that it works using LWLock instead.
> That's not a good idea because it'll make the code
On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada wrote:
> Currently, the relation extension lock is implemented using
> heavyweight lock manager and almost functions (except for
> brin_page_cleanup) using LockRelationForExntesion use it with
> ExclusiveLock mode. But
Hi all,
Currently, the relation extension lock is implemented using
heavyweight lock manager and almost functions (except for
brin_page_cleanup) using LockRelationForExntesion use it with
ExclusiveLock mode. But actually it doesn't need multiple lock modes
or deadlock detection or any of the
22 matches
Mail list logo