Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u046F-00AtIz-70 for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Apr 2025 19:50:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u046B-00HYsV-SF for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Apr 2025 19:50:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u046B-00HYsL-Fz for pgsql-hackers@lists.postgresql.org; Wed, 02 Apr 2025 19:50:07 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u0469-0031mf-13 for pgsql-hackers@lists.postgresql.org; Wed, 02 Apr 2025 19:50:07 +0000 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-ac3fcf5ab0dso23662266b.3 for ; Wed, 02 Apr 2025 12:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743623404; x=1744228204; darn=lists.postgresql.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=tBtzBtTdSzMVq57UVVaoe953gu+0YroJkVseso1KeZk=; b=d+6/LlyFunX13vlA6BfFQ1gOsM91IND16M14r/OUN61v/IHF1Z47Fg2FEY7k/b2r2D bC6FATCoZyCGiq1vmuUtlIkf2W1Nz0nX2NyS5l8jcd0bX270rMRYBiQeO7X1L4Qqzl1j Smuo1UygTuxl5fDGPnMG7jeytJC7WVEIK7c+adEFA9h2vjmGYLcyIOcr7Rlhrs5o/aDq P27q9STjbM2xsiXBu65YIyUU/sku2G9K1loUx+jbM1Tui74PZRY6e7ZPKCJgpAqTz+bD x1wLKtK5zJ66gW/yU7009wsdNUrbmjTs2F8dlfmHHSsAnT8sQWSladyHo/kRAv28EbRK OFbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743623404; x=1744228204; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=tBtzBtTdSzMVq57UVVaoe953gu+0YroJkVseso1KeZk=; b=U9XdVy63tuuIEj99Y1X5WHCZ53XmRPtit48s/1Wd3rpJfNInNXFD0L9KAQ0OiL7051 ivfgCogSfc8ShRKEZg+a3qfD9OfHum3JIMtT15Ow7wqS/tnM9wmbZeGklQ+25zvxVyuA mESwDNM02L6DMAcjCq22Ul6zcq4dUerWr4/L5DsRveAaviVCQrcTLMn2LYUxip0RbQGX 4QMT4ZHWNuC+Oyvn0NpjHoVxH/xIq8rKHo5duGIKQhckBlbaALJZ+olxKDCBlQgB+ANU bNYU33svPCNtadoCVJSIe25JXcmlwv1OjL+vM6KHgyJrQ7nXa/1FaOwVF30Izu6MI3/K 145w== X-Gm-Message-State: AOJu0YxH35WYWPIatxWzwj+DGz+RBw1lHp27TSMyJGTfuqPZIR/f/4bp dAi4AQ5XpLZyjqFhoKpMsuXHsMNlUPVeSwd+qg2MMApWj5bupHN5sZrzl4F+J3A= X-Gm-Gg: ASbGnctpCab43it7R+H0dOc9l4uF9z1OlNxBTHKne9z6fOGetG/xWnFRrX2CGMt92PK MqOfwSbRsQOW4D1b+AblMWf11iCZ6vadyDQwFO13mC8mpK2UPci3iSmihRxSi0ih7vaKtViStft /dYH/IR1++t60Yv2c7eeux45ijCXQ24tF2vxG53pIhvyyx2ouBnaJrrRcxq0FDc8nQ+Tf4ZSxkH b2gmkvSvURo98MEdZ4flmJ5hVoqKgnbjV9YZqWyCmT1mlPjNpEWi4SN2//gDo1jDWwsHU2sSwwR Gg7NITzFwrr6Jg6I9+C7thZWo5CA8/xPxBH/1NQLgfvpNqogqpHjj4LVNjB9 X-Google-Smtp-Source: AGHT+IFkBl+SJBwBVvNSTf5FkfMNLN11M9ZdyCiVhqeTKtCP7s/wMHGA6gDxaJyuVd0JL35h7u2Y0Q== X-Received: by 2002:a17:907:983:b0:ac6:d160:e3b9 with SMTP id a640c23a62f3a-ac7a16c35e1mr308274766b.22.1743623403559; Wed, 02 Apr 2025 12:50:03 -0700 (PDT) Received: from [172.16.216.65] ([195.209.39.131]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac71967ff84sm953002466b.133.2025.04.02.12.50.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Apr 2025 12:50:02 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------047WFY0Ed0893cFkIqO1Wqx3" Message-ID: <156d52ac-c502-4dc8-baa5-64b6d1b32e74@gmail.com> Date: Wed, 2 Apr 2025 22:50:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: LWLock deadlock in brinRevmapDesummarizeRange To: Alvaro Herrera , Tomas Vondra Cc: PostgreSQL Hackers References: <20230222144112.3zepouym4dbznwcr@alvherre.pgsql> Content-Language: en-US From: Arseniy Mukhin In-Reply-To: <20230222144112.3zepouym4dbznwcr@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------047WFY0Ed0893cFkIqO1Wqx3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Tomas and Alvaro, Came across this old thread while searching for information about brin, and decided to try to fix it. On 22.02.2023 17:41, Alvaro Herrera wrote: > On 2023-Feb-22, Tomas Vondra wrote: > >>> ... and in there, I wrote that we would first write the brin tuple in >>> the regular page, unlock that, and then lock the revmap for the update, >>> without holding lock on the data page.  I don't remember why we do it >>> differently now, but maybe the fix is just to release the regular page >>> lock before locking the revmap page?  One very important change is that >>> in previous versions the revmap used a separate fork, and we had to >>> introduce an "evacuation protocol" when we integrated the revmap into >>> the main fork, which may have changed the locking considerations. >> >> What would happen if two processes built the summary concurrently? How >> would they find the other tuple, so that we don't end up with two BRIN >> tuples for the same range? > > Well, the revmap can only keep track of one tuple per range; if two > processes build summary tuples, and each tries to insert its tuple in a > regular page, that part may succeed; but then only one of them is going > to successfully register the summary tuple in the revmap: when the other > goes to do the same, it would find that a CTID is already present. > > ... Looking at the code (brinSetHeapBlockItemptr), I think what happens > here is that the second process would overwrite the TID with its own. > Not sure if it would work to see whether the item is empty and bail out > if it's not. > AFAIS it's impossible to have two processes summarizing or desummarizing ranges simultaneously, because you need ShareUpdateExclusiveLock to do it. Usual inserts / updates can't lead to summarization, they affects only those ranges that are summarized already. >>> Another point: to desummarize a range, just unlinking the entry from >>> revmap should suffice, from the POV of other index scanners.  Maybe we >>> can simplify the whole procedure to: lock revmap, remove entry, remember >>> page number, unlock revmap; lock regular page, delete entry, unlock. >>> Then there are no two locks held at the same time during desummarize. >> >> Perhaps, as long as it doesn't confuse anything else. > > Well, I don't have the details fresh in mind, but I think it shouldn't, > because the only way to reach a regular tuple is coming from the revmap; > and we reuse "items" (lines) in a regular page only when they are > empty (so vacuuming should also be OK). > I think it would work, but there's one thing to handle in this case: You may have a concurrent update that moved the index tuple to another reg page and wants to update the revmap page with a new pointer. This may happen after the revmap entry is deleted, so you can have kind of lost update. But this seems to be easy to detect: when you try to delete the index tuple, you'll see an unused item. This means that a concurrent update moved index tuple and updated revmap page and you need to retry the desummarization. Also if you don't hold locks on both revmap page and regular pages, you will have to split wal record and rework recovery for desummarization. And probably in case of crash between revmap update and regular page update you can have dangling index tuple, so it seems that having one wal record for update simplifies recovery. I think there is a straightforward way to implement desummarization and fix the deadlock. Desummarization is actually very similar to usual update, so we can just use update flow (like brininsert or second part of summarize_range where you need to merge summary with placeholder tuple): - lock revmap page - save pointer to the index tuple - unlock revmap page - lock regular page - check if pointer is still valid (blkno is as expected, NORMAL tuple etc.)   if we see that pointer is not valid anymore -> unlock reg page + retry - lock revmap page - update reg page and revmap page First five steps have been implemented already in brinGetTupleForHeapBlock, so we can use it (like every update actually do, if I see correctly). Please find the attached patch implementing the above idea. I tried Tomas's stress tests with applied patch and didn't have deadlocks. Also there is a another way how issue can be reproduced: apply deadlock-sleep.patch (it just adds 15 sec sleep in brin_doupdate and few logs) execute deadlock.sql execute deadlock2.sql from another client (there are 15 seconds to do it while first process is sleeping). Best regards, Arseniy Mukhin --------------047WFY0Ed0893cFkIqO1Wqx3 Content-Type: text/x-patch; charset=UTF-8; name="0001-brin-desummarization-deadlock.patch" Content-Disposition: attachment; filename="0001-brin-desummarization-deadlock.patch" Content-Transfer-Encoding: base64 RnJvbSAzMWE4YTU1OGI4NDVjZGE2YjFlYzFkMTg4MjllMGY3ZmYwZWMzNTBkIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBcnNlbml5IE11a2hpbiA8YXJzZW5peS5tdWtoaW4u ZGV2QGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAyIEFwciAyMDI1IDIxOjU1OjI0ICswMzAwClN1 YmplY3Q6IFtQQVRDSF0gYnJpbiBkZXN1bW1hcml6YXRpb24gZGVhZGxvY2sKCi0tLQogc3Jj L2JhY2tlbmQvYWNjZXNzL2JyaW4vYnJpbi5jICAgICAgICB8ICA4ICstLQogc3JjL2JhY2tl bmQvYWNjZXNzL2JyaW4vYnJpbl9yZXZtYXAuYyB8IDcxICsrKysrKysrKysrKy0tLS0tLS0t LS0tLS0tLQogc3JjL2luY2x1ZGUvYWNjZXNzL2JyaW5fcmV2bWFwLmggICAgICB8ICAyICst CiAzIGZpbGVzIGNoYW5nZWQsIDMzIGluc2VydGlvbnMoKyksIDQ4IGRlbGV0aW9ucygtKQoK ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9icmluL2JyaW4uYyBiL3NyYy9iYWNr ZW5kL2FjY2Vzcy9icmluL2JyaW4uYwppbmRleCAwMWUxZGI3Zjg1Ni4uYzUyNjc3NTM0ZWQg MTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9icmluL2JyaW4uYworKysgYi9zcmMv YmFja2VuZC9hY2Nlc3MvYnJpbi9icmluLmMKQEAgLTE0OTYsNyArMTQ5Niw2IEBAIGJyaW5f ZGVzdW1tYXJpemVfcmFuZ2UoUEdfRlVOQ1RJT05fQVJHUykKIAlPaWQJCQloZWFwb2lkOwog CVJlbGF0aW9uCWhlYXBSZWw7CiAJUmVsYXRpb24JaW5kZXhSZWw7Ci0JYm9vbAkJZG9uZTsK IAogCWlmIChSZWNvdmVyeUluUHJvZ3Jlc3MoKSkKIAkJZXJlcG9ydChFUlJPUiwKQEAgLTE1 NTUsMTIgKzE1NTQsNyBAQCBicmluX2Rlc3VtbWFyaXplX3JhbmdlKFBHX0ZVTkNUSU9OX0FS R1MpCiAJLyogc2VlIGdpbl9jbGVhbl9wZW5kaW5nX2xpc3QoKSAqLwogCWlmIChpbmRleFJl bC0+cmRfaW5kZXgtPmluZGlzdmFsaWQpCiAJewotCQkvKiB0aGUgcmV2bWFwIGRvZXMgdGhl IGhhcmQgd29yayAqLwotCQlkbwotCQl7Ci0JCQlkb25lID0gYnJpblJldm1hcERlc3VtbWFy aXplUmFuZ2UoaW5kZXhSZWwsIGhlYXBCbGspOwotCQl9Ci0JCXdoaWxlICghZG9uZSk7CisJ CWJyaW5SZXZtYXBEZXN1bW1hcml6ZVJhbmdlKGluZGV4UmVsLCBoZWFwQmxrKTsKIAl9CiAJ ZWxzZQogCQllcmVwb3J0KERFQlVHMSwKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vz cy9icmluL2JyaW5fcmV2bWFwLmMgYi9zcmMvYmFja2VuZC9hY2Nlc3MvYnJpbi9icmluX3Jl dm1hcC5jCmluZGV4IDRlMzgwZWNjNzEwLi5kM2VmMDNkMzRhZSAxMDA2NDQKLS0tIGEvc3Jj L2JhY2tlbmQvYWNjZXNzL2JyaW4vYnJpbl9yZXZtYXAuYworKysgYi9zcmMvYmFja2VuZC9h Y2Nlc3MvYnJpbi9icmluX3Jldm1hcC5jCkBAIC0zMTYsMTAgKzMxNiw4IEBAIGJyaW5HZXRU dXBsZUZvckhlYXBCbG9jayhCcmluUmV2bWFwICpyZXZtYXAsIEJsb2NrTnVtYmVyIGhlYXBC bGssCiAgKiBEZWxldGUgYW4gaW5kZXggdHVwbGUsIG1hcmtpbmcgYSBwYWdlIHJhbmdlIGFz IHVuc3VtbWFyaXplZC4KICAqCiAgKiBJbmRleCBtdXN0IGJlIGxvY2tlZCBpbiBTaGFyZVVw ZGF0ZUV4Y2x1c2l2ZUxvY2sgbW9kZS4KLSAqCi0gKiBSZXR1cm4gZmFsc2UgaWYgY2FsbGVy IHNob3VsZCByZXRyeS4KICAqLwotYm9vbAordm9pZAogYnJpblJldm1hcERlc3VtbWFyaXpl UmFuZ2UoUmVsYXRpb24gaWR4cmVsLCBCbG9ja051bWJlciBoZWFwQmxrKQogewogCUJyaW5S ZXZtYXAgKnJldm1hcDsKQEAgLTMyNywyNiArMzI1LDM3IEBAIGJyaW5SZXZtYXBEZXN1bW1h cml6ZVJhbmdlKFJlbGF0aW9uIGlkeHJlbCwgQmxvY2tOdW1iZXIgaGVhcEJsaykKIAlSZXZt YXBDb250ZW50cyAqY29udGVudHM7CiAJSXRlbVBvaW50ZXJEYXRhICppcHRyOwogCUl0ZW1Q b2ludGVyRGF0YSBpbnZhbGlkSXB0cjsKLQlCbG9ja051bWJlciByZXZtYXBCbGs7CiAJQnVm ZmVyCQlyZXZtYXBCdWY7Ci0JQnVmZmVyCQlyZWdCdWY7CisJQnVmZmVyCQlyZWdCdWYgPSBJ bnZhbGlkQnVmZmVyOwogCVBhZ2UJCXJldm1hcFBnOwogCVBhZ2UJCXJlZ1BnOwogCU9mZnNl dE51bWJlciByZXZtYXBPZmZzZXQ7CiAJT2Zmc2V0TnVtYmVyIHJlZ09mZnNldDsKLQlJdGVt SWQJCWxwOworCUJyaW5UdXBsZSAgKmJ0dXA7CisJU2l6ZQkJc2l6ZTsKIAogCXJldm1hcCA9 IGJyaW5SZXZtYXBJbml0aWFsaXplKGlkeHJlbCwgJnBhZ2VzUGVyUmFuZ2UpOwogCi0JcmV2 bWFwQmxrID0gcmV2bWFwX2dldF9ibGtubyhyZXZtYXAsIGhlYXBCbGspOwotCWlmICghQmxv Y2tOdW1iZXJJc1ZhbGlkKHJldm1hcEJsaykpCisJLyogVHJ5IHRvIGdldCBpbmRleCB0dXBs ZSBmb3IgdGhlIHRhcmdldCBibG9jayBudW1iZXIgKi8KKwlidHVwID0gYnJpbkdldFR1cGxl Rm9ySGVhcEJsb2NrKHJldm1hcCwgaGVhcEJsaywgJnJlZ0J1ZiwgJnJlZ09mZnNldCwgJnNp emUsIEJVRkZFUl9MT0NLX0VYQ0xVU0lWRSk7CisKKwkvKiBJZiByYW5nZSBpcyBub3Qgc3Vt bWFyaXplZCwgcmVsZWFzZSByZXNvdXJjZXMgYW5kIHdlIGFyZSBkb25lICovCisJaWYgKCFi dHVwKQogCXsKLQkJLyogcmV2bWFwIHBhZ2UgZG9lc24ndCBleGlzdDogcmFuZ2Ugbm90IHN1 bW1hcml6ZWQsIHdlJ3JlIGRvbmUgKi8KKwkJaWYgKEJ1ZmZlcklzVmFsaWQocmVnQnVmKSkK KwkJeworCQkJUmVsZWFzZUJ1ZmZlcihyZWdCdWYpOworCQl9CiAJCWJyaW5SZXZtYXBUZXJt aW5hdGUocmV2bWFwKTsKLQkJcmV0dXJuIHRydWU7CisKKwkJcmV0dXJuOwogCX0KIAotCS8q IExvY2sgdGhlIHJldm1hcCBwYWdlLCBvYnRhaW4gdGhlIGluZGV4IHR1cGxlIHBvaW50ZXIg ZnJvbSBpdCAqLworCS8qCisJICogV2Uga25vdyB0aGF0IHJhbmdlIGlzIHN1bW1hcml6ZWQg KG9yIGl0J3MgYSBkYW5nbGluZyBwbGFjZWhvbGRlciksIGFuZAorCSAqIHdlIGhhdmUgdGhl IHJlZ3VsYXIgcGFnZSB3aXRoIHRoZSBpbmRleCB0dXBsZSBsb2NrZWQgZXhjbHVzaXZlbHku IE5vdworCSAqIGxvY2sgdGhlIHJldm1hcCBwYWdlIHdpdGggcG9pbnRlciB0byBvdXIgaW5k ZXggdHVwbGUKKwkgKi8KIAlyZXZtYXBCdWYgPSBicmluTG9ja1Jldm1hcFBhZ2VGb3JVcGRh dGUocmV2bWFwLCBoZWFwQmxrKTsKIAlyZXZtYXBQZyA9IEJ1ZmZlckdldFBhZ2UocmV2bWFw QnVmKTsKIAlyZXZtYXBPZmZzZXQgPSBIRUFQQkxLX1RPX1JFVk1BUF9JTkRFWChyZXZtYXAt PnJtX3BhZ2VzUGVyUmFuZ2UsIGhlYXBCbGspOwpAQCAtMzU1LDM4ICszNjQsMjIgQEAgYnJp blJldm1hcERlc3VtbWFyaXplUmFuZ2UoUmVsYXRpb24gaWR4cmVsLCBCbG9ja051bWJlciBo ZWFwQmxrKQogCWlwdHIgPSBjb250ZW50cy0+cm1fdGlkczsKIAlpcHRyICs9IHJldm1hcE9m ZnNldDsKIAotCWlmICghSXRlbVBvaW50ZXJJc1ZhbGlkKGlwdHIpKQotCXsKLQkJLyogbm8g aW5kZXggdHVwbGU6IHJhbmdlIG5vdCBzdW1tYXJpemVkLCB3ZSdyZSBkb25lICovCi0JCUxv Y2tCdWZmZXIocmV2bWFwQnVmLCBCVUZGRVJfTE9DS19VTkxPQ0spOwotCQlicmluUmV2bWFw VGVybWluYXRlKHJldm1hcCk7Ci0JCXJldHVybiB0cnVlOwotCX0KLQotCXJlZ0J1ZiA9IFJl YWRCdWZmZXIoaWR4cmVsLCBJdGVtUG9pbnRlckdldEJsb2NrTnVtYmVyKGlwdHIpKTsKLQlM b2NrQnVmZmVyKHJlZ0J1ZiwgQlVGRkVSX0xPQ0tfRVhDTFVTSVZFKTsKLQlyZWdQZyA9IEJ1 ZmZlckdldFBhZ2UocmVnQnVmKTsKLQotCS8qIGlmIHRoaXMgaXMgbm8gbG9uZ2VyIGEgcmVn dWxhciBwYWdlLCB0ZWxsIGNhbGxlciB0byBzdGFydCBvdmVyICovCi0JaWYgKCFCUklOX0lT X1JFR1VMQVJfUEFHRShyZWdQZykpCisJLyoKKwkgKiBObyBjb25jdXJyZW50IHVwZGF0ZXMg Zm9yIHRoZSByYW5nZSBhcmUgcG9zc2libGUgYXMgYW55IHVwZGF0ZSBzaG91bGQKKwkgKiBs b2NrIHJlZ3VsYXIgcGFnZSBmaXJzdCwgYW5kIHdlIGFscmVhZHkgaG9sZCB0aGUgbG9jay4g V2Uga25vdyB0aGF0CisJICogaW5kZXggdHVwbGUgZm9yIHRoZSByYW5nZSBleGlzdHMsIHNv IHJldm1hcCBpdGVtIHBvaW50ZXIgY291bGRuJ3QgYmUKKwkgKiBpbnZhbGlkIGFuZCBzaG91 bGQgcG9pbnQgdG8gaW5kZXggdHVwbGUgYnR1cC4KKwkgKi8KKwlpZiAoIUl0ZW1Qb2ludGVy SXNWYWxpZChpcHRyKSB8fAorCQlJdGVtUG9pbnRlckdldEJsb2NrTnVtYmVyKGlwdHIpICE9 IEJ1ZmZlckdldEJsb2NrTnVtYmVyKHJlZ0J1ZikgfHwKKwkJSXRlbVBvaW50ZXJHZXRPZmZz ZXROdW1iZXIoaXB0cikgIT0gcmVnT2Zmc2V0KQogCXsKLQkJTG9ja0J1ZmZlcihyZXZtYXBC dWYsIEJVRkZFUl9MT0NLX1VOTE9DSyk7Ci0JCUxvY2tCdWZmZXIocmVnQnVmLCBCVUZGRVJf TE9DS19VTkxPQ0spOwotCQlicmluUmV2bWFwVGVybWluYXRlKHJldm1hcCk7Ci0JCXJldHVy biBmYWxzZTsKLQl9Ci0KLQlyZWdPZmZzZXQgPSBJdGVtUG9pbnRlckdldE9mZnNldE51bWJl cihpcHRyKTsKLQlpZiAocmVnT2Zmc2V0ID4gUGFnZUdldE1heE9mZnNldE51bWJlcihyZWdQ ZykpCiAJCWVyZXBvcnQoRVJST1IsCiAJCQkJKGVycmNvZGUoRVJSQ09ERV9JTkRFWF9DT1JS VVBURUQpLAogCQkJCSBlcnJtc2coImNvcnJ1cHRlZCBCUklOIGluZGV4OiBpbmNvbnNpc3Rl bnQgcmFuZ2UgbWFwIikpKTsKKwl9CiAKLQlscCA9IFBhZ2VHZXRJdGVtSWQocmVnUGcsIHJl Z09mZnNldCk7Ci0JaWYgKCFJdGVtSWRJc1VzZWQobHApKQotCQllcmVwb3J0KEVSUk9SLAot CQkJCShlcnJjb2RlKEVSUkNPREVfSU5ERVhfQ09SUlVQVEVEKSwKLQkJCQkgZXJybXNnKCJj b3JydXB0ZWQgQlJJTiBpbmRleDogaW5jb25zaXN0ZW50IHJhbmdlIG1hcCIpKSk7CisJcmVn UGcgPSBCdWZmZXJHZXRQYWdlKHJlZ0J1Zik7CiAKIAkvKgogCSAqIFBsYWNlaG9sZGVyIHR1 cGxlcyBvbmx5IGFwcGVhciBkdXJpbmcgdW5maW5pc2hlZCBzdW1tYXJpemF0aW9uLCBhbmQg d2UKQEAgLTQyOSw4ICs0MjIsNiBAQCBicmluUmV2bWFwRGVzdW1tYXJpemVSYW5nZShSZWxh dGlvbiBpZHhyZWwsIEJsb2NrTnVtYmVyIGhlYXBCbGspCiAJVW5sb2NrUmVsZWFzZUJ1ZmZl cihyZWdCdWYpOwogCUxvY2tCdWZmZXIocmV2bWFwQnVmLCBCVUZGRVJfTE9DS19VTkxPQ0sp OwogCWJyaW5SZXZtYXBUZXJtaW5hdGUocmV2bWFwKTsKLQotCXJldHVybiB0cnVlOwogfQog CiAvKgpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvYWNjZXNzL2JyaW5fcmV2bWFwLmggYi9z cmMvaW5jbHVkZS9hY2Nlc3MvYnJpbl9yZXZtYXAuaAppbmRleCBiODg0NzNjOTg2MC4uMzIy MTA5ZTkwM2QgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRlL2FjY2Vzcy9icmluX3Jldm1hcC5o CisrKyBiL3NyYy9pbmNsdWRlL2FjY2Vzcy9icmluX3Jldm1hcC5oCkBAIC0zNiw2ICszNiw2 IEBAIGV4dGVybiB2b2lkIGJyaW5TZXRIZWFwQmxvY2tJdGVtcHRyKEJ1ZmZlciBidWYsIEJs b2NrTnVtYmVyIHBhZ2VzUGVyUmFuZ2UsCiBleHRlcm4gQnJpblR1cGxlICpicmluR2V0VHVw bGVGb3JIZWFwQmxvY2soQnJpblJldm1hcCAqcmV2bWFwLAogCQkJCQkJCQkJCSAgIEJsb2Nr TnVtYmVyIGhlYXBCbGssIEJ1ZmZlciAqYnVmLCBPZmZzZXROdW1iZXIgKm9mZiwKIAkJCQkJ CQkJCQkgICBTaXplICpzaXplLCBpbnQgbW9kZSk7Ci1leHRlcm4gYm9vbCBicmluUmV2bWFw RGVzdW1tYXJpemVSYW5nZShSZWxhdGlvbiBpZHhyZWwsIEJsb2NrTnVtYmVyIGhlYXBCbGsp OworZXh0ZXJuIHZvaWQgYnJpblJldm1hcERlc3VtbWFyaXplUmFuZ2UoUmVsYXRpb24gaWR4 cmVsLCBCbG9ja051bWJlciBoZWFwQmxrKTsKIAogI2VuZGlmCQkJCQkJCS8qIEJSSU5fUkVW TUFQX0ggKi8KLS0gCjIuNDMuMAoK --------------047WFY0Ed0893cFkIqO1Wqx3 Content-Type: application/sql; name="deadlock.sql" Content-Disposition: attachment; filename="deadlock.sql" Content-Transfer-Encoding: base64 Y3JlYXRlIG9yIHJlcGxhY2UgZnVuY3Rpb24gIHJhbmRvbV9zdHJpbmcoIGludCApIHJldHVy bnMgdGV4dCBhcyAkJApzZWxlY3Qgc3RyaW5nX2FnZyhzdWJzdHJpbmcoJzAxMjM0NTY3ODli Y2RmZ2hqa21ucHFyc3R2d3h5eicsIGNlaWwocmFuZG9tKCkgKiAzMCk6OmludGVnZXIsIDEp LCAnJykgZnJvbSBnZW5lcmF0ZV9zZXJpZXMoMSwgJDEpOwokJCBsYW5ndWFnZSBzcWw7Cgpk cm9wIHRhYmxlIGlmIGV4aXN0cyB0MTsKY3JlYXRlIHRhYmxlIGlmIG5vdCBleGlzdHMgdDEg KGEgdmFyY2hhcikgd2l0aCAoZmlsbGZhY3RvciA9MjApOwoKLS0gaW5zZXJ0IHR1cGxlLCBp dCB3aWxsIGJlIHRoZSBvbmx5IHR1cGxlIGluIHRoZSAxIHJhbmdlCmluc2VydCBpbnRvIHQx IChhKSBWQUxVRVMgKHJhbmRvbV9zdHJpbmcoMjAwMCkpOwoKLS0gaW5zZXJ0IHR1cGxlLCBp dCB3aWxsIGJlIHRoZSBvbmx5IHR1cGxlIGluIHRoZSAyIHJhbmdlCmluc2VydCBpbnRvIHQx IChhKSBWQUxVRVMgKHJhbmRvbV9zdHJpbmcoMjAwMCkpOwoKLS0gaW5zZXJ0IHR1cGxlLiBm aXJzdCB0dXBsZSBpbiB0aGUgMyByYW5nZS4gaXQncyBzbWFsbCBlbm91Z2ggc28gbmV4dCBp bnNlcnQgY2FuIHB1dCB0dXBsZSBpbiAzIHJhbmdlLgppbnNlcnQgaW50byB0MSAoYSkgVkFM VUVTIChyYW5kb21fc3RyaW5nKDIwKSk7CgpjcmVhdGUgaW5kZXggdDFfYV9icmluX2lkeCBv biB0MSB1c2luZyBicmluIChhKSB3aXRoIChwYWdlc19wZXJfcmFuZ2UgPSAxKSA7CgotLSBp bnNlcnQgbGVhZHMgdG8gdXBkYXRlIG9mIGJyaW4gdHVwbGUgZm9yIHRoZSAzcmQgcmFuZ2Us IGJ1dCBuZXcgdmVyc2lvbiBuZWVkcyBtb3JlIHNwYWNlIGFuZCBjdXJyZW50IHJlZ3VsYXIg cGFnZSBkb2Vzbid0IGhhdmUgaXQgc28KLS0gdGhpcyByZXN1bHRzIGluIHRoZSBicmluIHR1 cGxlIGZvciAzIHJhbmdlIGJlaW5nIG1vdmVkIHRvIGFub3RoZXIgcmVndWxhciBwYWdlIGFu ZCByZXZtYXAgZW50cnkgZm9yIDNyZCByYW5nZSBiZWluZyB1cGRhdGVkLgotLSBsb2NrIG9y ZGVyaW5nIGluIHRoaXMgY2FzZTogcmVnIHBhZ2UgbG9jayAtPiByZXZtYXAgcGFnZSBsb2Nr Cmluc2VydCBpbnRvIHQxIChhKSBWQUxVRVMgKHJhbmRvbV9zdHJpbmcoMjAzMCkpOw== --------------047WFY0Ed0893cFkIqO1Wqx3 Content-Type: application/sql; name="deadlock2.sql" Content-Disposition: attachment; filename="deadlock2.sql" Content-Transfer-Encoding: base64 LS0gY2FsbCBkZXN1bW1hcml6YXRpb24sIGxvY2sgb3JkZXJpbmc6IHJldm1hcCBwYWdlIC0+ IHJlZyBwYWdlCnNlbGVjdCBicmluX2Rlc3VtbWFyaXplX3JhbmdlKCd0MV9hX2JyaW5faWR4 Jzo6cmVnY2xhc3MsIDEpOw== --------------047WFY0Ed0893cFkIqO1Wqx3 Content-Type: text/x-patch; charset=UTF-8; name="deadlock-sleep.patch" Content-Disposition: attachment; filename="deadlock-sleep.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9icmluL2JyaW5fcGFnZW9wcy5jIGIv c3JjL2JhY2tlbmQvYWNjZXNzL2JyaW4vYnJpbl9wYWdlb3BzLmMKaW5kZXggNmQ4ZGQxNTEy ZDYuLjljM2FkMWYwYmFiIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9hY2Nlc3MvYnJpbi9i cmluX3BhZ2VvcHMuYworKysgYi9zcmMvYmFja2VuZC9hY2Nlc3MvYnJpbi9icmluX3BhZ2Vv cHMuYwpAQCAtMjM3LDggKzIzNywxMSBAQCBicmluX2RvdXBkYXRlKFJlbGF0aW9uIGlkeHJl bCwgQmxvY2tOdW1iZXIgcGFnZXNQZXJSYW5nZSwKIAkJT2Zmc2V0TnVtYmVyIG5ld29mZjsK IAkJU2l6ZQkJZnJlZXNwYWNlID0gMDsKIAorICAgICAgICBlbG9nKERFQlVHMSwgInNsZWVw IHdoaWxlIHVwZGF0ZSIpOworICAgICAgICBzbGVlcCgxNSk7CisgICAgICAgIGVsb2coREVC VUcxLCAiVHJ5IHRvIHJldm1hcCBmb3IgdXBkYXRlIHJlZyBwYWdlIC0gdXBkYXRlIik7CiAJ CXJldm1hcGJ1ZiA9IGJyaW5Mb2NrUmV2bWFwUGFnZUZvclVwZGF0ZShyZXZtYXAsIGhlYXBC bGspOwotCisgICAgICAgIGVsb2coREVCVUcxLCAiVHJ5IHRvIHJldm1hcCBmb3IgdXBkYXRl IHJlZyBwYWdlIC0gdXBkYXRlIik7CiAJCVNUQVJUX0NSSVRfU0VDVElPTigpOwogCiAJCS8q Cg== --------------047WFY0Ed0893cFkIqO1Wqx3--