Re: BUG #8434: Why does dead lock occur many times ?

From: Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8434: Why does dead lock occur many times ?
Date: 2013-11-28 04:00:33
Message-ID: 5296BFE1.2090906@po.ntts.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Alvaro

I applied all patches you told me against 93_STABLE.
But I could not build the source with the patches.

It seems your patch use GetMultiXactIdMembers with four arguments,
but the function requires three arguments.
----
nmembers = GetMultiXactIdMembers(rawxmax, &members, false, false);
----

do you have another patch?

Am I missing something?

(2013/11/28 1:42), Alvaro Herrera wrote:
> I think I have figured this out. This code was being too simplistic in
> that it was only checking whether there was a key-update or not; but
> that, it seems, is not sufficiently fine-grained. If we instead think
> in terms of an already-acquired MultiXactStatus, and a new
> MultiXactStatus corresponding to the lock we're trying to acquire, we
> can decide granularly whether each future version of the tuple can be
> locked by us or not. And if not, we can decide whether we need to wait
> on the transaction holding the lock, or fail if it already committed.
> (There is a funny trick here which is that we represent the held lock
> with a MultiXactStatus, even if the lock is only a plain Xid and not a
> multi. This doesn't seem a problem to me.)
>
> So I propose the attached patch. This doesn't change the behavior
> codified in the existing isolation tests, and it fixes my reduction of
> your original test case. (I haven't run your original test case yet,
> but I soon will.)
>
> Note: I don't quite like that this patch duplicates some code in
> compute_new_xmax_infomask() which determines the MultiXactStatus from
> the infomask bits. Not sure what a good refactoring is, though, because
> that code just issues a WARNING when the LOCK_ONLY bit is set and no
> other lockmode is set; whereas the new code issues an ERROR. It seems
> hard to justify doing otherwise in either place, though; and doing
> something more complicated doesn't seem warranted for such a corner
> case.
>
> Note: this patch doesn't apply to master in isolation. You will need
> the patch I mention in
>
http://www.postgresql.org/message-id/20131125201039.GF6597@eldon.alvh.no-ip.org
> even though I haven't posted it yet. Will do so shortly.
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2013-11-28 07:44:23 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Alvaro Herrera 2013-11-28 02:56:54 Re: BUG #8632: file "pg_subtrans/CEC0" doesn't exist, reading as zeroes