Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1korD6-0002k5-4N for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Dec 2020 17:00:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1korD4-0000hF-8V for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Dec 2020 17:00:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1korD3-0000h8-VE for pgsql-hackers@lists.postgresql.org; Mon, 14 Dec 2020 17:00:30 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1korD0-0004bb-KY for pgsql-hackers@postgresql.org; Mon, 14 Dec 2020 17:00:29 +0000 Received: from hnk.local (p1295030-ipngn4902funabasi.chiba.ocn.ne.jp [153.166.85.30]) by oss.nttdata.com (Postfix) with ESMTPSA id 08F51625EC; Tue, 15 Dec 2020 02:00:22 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: Add Information during standby recovery conflicts To: "Drouvot, Bertrand" , Masahiko Sawada Cc: Alvaro Herrera , Masahiko Sawada , Kyotaro Horiguchi , PostgreSQL-development References: <20201130182528.GA1854@alvherre.pgsql> <594f4419-62aa-c272-ef7d-4287e5c6b654@amazon.com> <627f702d-a04c-b72b-b94f-214f448e2935@oss.nttdata.com> <73037867-b688-c5cc-5f6d-ad73db6ab94d@amazon.com> <02b17df8-cf11-7e5a-31e3-d94c87b28775@oss.nttdata.com> <8c1fca5b-6c5c-df6f-0b6d-4702eeb11c5c@amazon.com> From: Fujii Masao Message-ID: <02295c62-e90f-9bf7-63ba-1ccda204aa71@oss.nttdata.com> Date: Tue, 15 Dec 2020 02:00:21 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <8c1fca5b-6c5c-df6f-0b6d-4702eeb11c5c@amazon.com> Content-Type: multipart/mixed; boundary="------------DF2A51BA6B21302B26FE2FDF" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------DF2A51BA6B21302B26FE2FDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020/12/15 0:49, Drouvot, Bertrand wrote: > Hi, > > On 12/14/20 4:20 PM, Fujii Masao wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. >> >> >> >> On 2020/12/14 21:31, Fujii Masao wrote: >>> >>> >>> On 2020/12/05 12:38, Masahiko Sawada wrote: >>>> On Fri, Dec 4, 2020 at 7:22 PM Drouvot, Bertrand wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 12/4/20 2:21 AM, Fujii Masao wrote: >>>>>> >>>>>> On 2020/12/04 9:28, Masahiko Sawada wrote: >>>>>>> On Fri, Dec 4, 2020 at 2:54 AM Fujii Masao >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2020/12/01 17:29, Drouvot, Bertrand wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 12/1/20 12:35 AM, Masahiko Sawada wrote: >>>>>>>>>> CAUTION: This email originated from outside of the organization. >>>>>>>>>> Do not click links or open attachments unless you can confirm the >>>>>>>>>> sender and know the content is safe. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Dec 1, 2020 at 3:25 AM Alvaro Herrera >>>>>>>>>> wrote: >>>>>>>>>>> On 2020-Dec-01, Fujii Masao wrote: >>>>>>>>>>> >>>>>>>>>>>> +                     if (proc) >>>>>>>>>>>> +                     { >>>>>>>>>>>> +                             if (nprocs == 0) >>>>>>>>>>>> + appendStringInfo(&buf, "%d", proc->pid); >>>>>>>>>>>> +                             else >>>>>>>>>>>> + appendStringInfo(&buf, ", %d", proc->pid); >>>>>>>>>>>> + >>>>>>>>>>>> +                             nprocs++; >>>>>>>>>>>> >>>>>>>>>>>> What happens if all the backends in wait_list have gone? In >>>>>>>>>>>> other words, >>>>>>>>>>>> how should we handle the case where nprocs == 0 (i.e., nprocs >>>>>>>>>>>> has not been >>>>>>>>>>>> incrmented at all)? This would very rarely happen, but can happen. >>>>>>>>>>>> In this case, since buf.data is empty, at least there seems no >>>>>>>>>>>> need to log >>>>>>>>>>>> the list of conflicting processes in detail message. >>>>>>>>>>> Yes, I noticed this too; this can be simplified by changing the >>>>>>>>>>> condition in the ereport() call to be "nprocs > 0" (rather than >>>>>>>>>>> wait_list being null), otherwise not print the errdetail.  (You >>>>>>>>>>> could >>>>>>>>>>> test buf.data or buf.len instead, but that seems uglier to me.) >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Maybe we can also improve the comment of this function from: >>>>>>>>>> >>>>>>>>>> + * This function also reports the details about the conflicting >>>>>>>>>> + * process ids if *wait_list is not NULL. >>>>>>>>>> >>>>>>>>>> to " This function also reports the details about the conflicting >>>>>>>>>> process ids if exist" or something. >>>>>>>>>> >>>>>>>>> Thank you all for the review/remarks. >>>>>>>>> >>>>>>>>> They have been addressed in the new attached patch version. >>>>>>>> >>>>>>>> Thanks for updating the patch! I read through the patch again >>>>>>>> and applied the following chages to it. Attached is the updated >>>>>>>> version of the patch. Could you review this version? If there is >>>>>>>> no issue in it, I'm thinking to commit this version. >>>>>>> >>>>>>> Thank you for updating the patch! I have one question. >>>>>>> >>>>>>>> >>>>>>>> +                       timeouts[cnt].id = STANDBY_TIMEOUT; >>>>>>>> +                       timeouts[cnt].type = TMPARAM_AFTER; >>>>>>>> +                       timeouts[cnt].delay_ms = DeadlockTimeout; >>>>>>>> >>>>>>>> Maybe STANDBY_TIMEOUT should be STANDBY_DEADLOCK_TIMEOUT here? >>>>>>>> I changed the code that way. >>>>>>> >>>>>>> As the comment of ResolveRecoveryConflictWithLock() says the >>>>>>> following, a deadlock is detected by the ordinary backend process: >>>>>>> >>>>>>>    * Deadlocks involving the Startup process and an ordinary backend >>>>>>> proces >>>>>>>    * will be detected by the deadlock detector within the ordinary >>>>>>> backend. >>>>>>> >>>>>>> If we use STANDBY_DEADLOCK_TIMEOUT, >>>>>>> SendRecoveryConflictWithBufferPin() will be called after >>>>>>> DeadlockTimeout passed, but I think it's not necessary for the startup >>>>>>> process in this case. >>>>>> >>>>>> Thanks for pointing this! You are right. >>>>>> >>>>>> >>>>>>> If we want to just wake up the startup process >>>>>>> maybe we can use STANDBY_TIMEOUT here? >>>>>> >>>>> Thanks for the patch updates! Except what we are still discussing below, >>>>> it looks good to me. >>>>> >>>>>> When STANDBY_TIMEOUT happens, a request to release conflicting buffer >>>>>> pins is sent. Right? If so, we should not also use STANDBY_TIMEOUT there? >>>>> >>>>> Agree >>>>> >>>>>> >>>>>> Or, first of all, we don't need to enable the deadlock timer at all? >>>>>> Since what we'd like to do is to wake up after deadlock_timeout >>>>>> passes, we can do that by changing ProcWaitForSignal() so that it can >>>>>> accept the timeout and giving the deadlock_timeout to it. If we do >>>>>> this, maybe we can get rid of STANDBY_LOCK_TIMEOUT from >>>>>> ResolveRecoveryConflictWithLock(). Thought? >>>> >>>> Where do we enable deadlock timeout in hot standby case? You meant to >>>> enable it in ProcWaitForSignal() or where we set a timer for not hot >>>> standby case, in ProcSleep()? >>> >>> No, what I tried to say is to change ResolveRecoveryConflictWithLock() so that it does >>> >>> 1. calculate the "minimum" timeout from deadlock_timeout and max_standby_xxx_delay >>> 2. give the calculated timeout value to ProcWaitForSignal() >>> 3. wait for signal and timeout on ProcWaitForSignal() >>> >>> Since ProcWaitForSignal() calls WaitLatch(), seems it's not so difficult to make ProcWaitForSignal() handle the timeout. If we do this, I was thinking that we can get rid of enable_timeouts() from ResolveRecoveryConflictWithLock(). >>> >>> >>>> >>>>> >>>>> Why not simply use (again) the STANDBY_LOCK_TIMEOUT one? (as it triggers >>>>> a call to StandbyLockTimeoutHandler() which does nothing, except waking >>>>> up. That's what we want, right?) >>>> >>>> Right, what I wanted to mean is STANDBY_LOCK_TIMEOUT. The startup >>>> process can wake up and do nothing. Thank you for pointing out. >>> >>> Okay, understood! Firstly I was thinking that enabling the same type (i.e., STANDBY_LOCK_TIMEOUT) of lock twice doesn't work properly, but as far as I read the code, it works. In that case, only the shorter timeout would be activated in enable_timeouts(). So I agree to use STANDBY_LOCK_TIMEOUT. >> >> So I renamed the argument "deadlock_timer" in ResolveRecoveryConflictWithLock() >> because it's not the timer for deadlock and is confusing. Attached is the >> updated version of the patch. Barring any objection, I will commit this version. > > Thanks for the update! > > Indeed the naming is more appropriate and less confusing that way, this version looks all good to me. Thanks for the review! I'm thinking to wait half a day before commiting the patch just in the case someone may object the patch. BTW, attached is the POC patch that implements the idea discussed upthread; if log_recovery_conflict_waits is enabled, the startup process reports the log also after the recovery conflict was resolved and the startup process finished waiting for it. This patch needs to be applied after v11-0002-Log-the-standby-recovery-conflict-waits.patch is applied. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION --------------DF2A51BA6B21302B26FE2FDF Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="log_recovery_conflict_waits_after_resolve.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="log_recovery_conflict_waits_after_resolve.patch" ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9jb25maWcuc2dtbCBiL2RvYy9zcmMvc2dtbC9j b25maWcuc2dtbAppbmRleCBlMDVmNmViNzMyLi4xYzAyYjZiMDQyIDEwMDY0NAotLS0gYS9k b2Mvc3JjL3NnbWwvY29uZmlnLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21sL2NvbmZpZy5zZ21s CkBAIC02OTU1LDcgKzY5NTUsNyBAQCBsb2dfbGluZV9wcmVmaXggPSAnJW0gWyVwXSAlcSV1 QCVkLyVhICcKICAgICAgIDxsaXN0aXRlbT4KICAgICAgICA8cGFyYT4KICAgICAgICAgQ29u dHJvbHMgd2hldGhlciBhIGxvZyBtZXNzYWdlIGlzIHByb2R1Y2VkIHdoZW4gdGhlIHN0YXJ0 dXAgcHJvY2VzcwotICAgICAgICBpcyB3YWl0aW5nIGxvbmdlciB0aGFuIDx2YXJuYW1lPmRl YWRsb2NrX3RpbWVvdXQ8L3Zhcm5hbWU+CisgICAgICAgIHdhaXRzIGxvbmdlciB0aGFuIDx2 YXJuYW1lPmRlYWRsb2NrX3RpbWVvdXQ8L3Zhcm5hbWU+CiAgICAgICAgIGZvciByZWNvdmVy eSBjb25mbGljdHMuICBUaGlzIGlzIHVzZWZ1bCBpbiBkZXRlcm1pbmluZyBpZiByZWNvdmVy eQogICAgICAgICBjb25mbGljdHMgcHJldmVudCB0aGUgcmVjb3ZlcnkgZnJvbSBhcHBseWlu ZyBXQUwuCiAgICAgICAgPC9wYXJhPgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvc3RvcmFn ZS9idWZmZXIvYnVmbWdyLmMgYi9zcmMvYmFja2VuZC9zdG9yYWdlL2J1ZmZlci9idWZtZ3Iu YwppbmRleCA4NDk5ZWE1NGY1Li4zNDQyZjBiYzY2IDEwMDY0NAotLS0gYS9zcmMvYmFja2Vu ZC9zdG9yYWdlL2J1ZmZlci9idWZtZ3IuYworKysgYi9zcmMvYmFja2VuZC9zdG9yYWdlL2J1 ZmZlci9idWZtZ3IuYwpAQCAtMzg0Nyw2ICszODQ3LDE1IEBAIExvY2tCdWZmZXJGb3JDbGVh bnVwKEJ1ZmZlciBidWZmZXIpCiAJCQkvKiBTdWNjZXNzZnVsbHkgYWNxdWlyZWQgZXhjbHVz aXZlIGxvY2sgd2l0aCBwaW5jb3VudCAxICovCiAJCQlVbmxvY2tCdWZIZHIoYnVmSGRyLCBi dWZfc3RhdGUpOwogCisJCQkvKgorCQkJICogRW1pdCB0aGUgbG9nIG1lc3NhZ2UgaWYgcmVj b3ZlcnkgY29uZmxpY3Qgb24gYnVmZmVyIHBpbiB3YXMgcmVzb2x2ZWQgYnV0CisJCQkgKiB0 aGUgc3RhcnR1cCBwcm9jZXNzIHdhaXRlZCBsb25nZXIgdGhhbiBkZWFkbG9ja190aW1lb3V0 IGZvciBpdC4KKwkJCSAqLworCQkJaWYgKGxvZ2dlZF9yZWNvdmVyeV9jb25mbGljdCkKKwkJ CQlMb2dSZWNvdmVyeUNvbmZsaWN0KFBST0NTSUdfUkVDT1ZFUllfQ09ORkxJQ1RfQlVGRkVS UElOLAorCQkJCQkJCQkJd2FpdFN0YXJ0LCBHZXRDdXJyZW50VGltZXN0YW1wKCksCisJCQkJ CQkJCQlOVUxMLCBmYWxzZSk7CisKIAkJCS8qIFJlcG9ydCBjaGFuZ2UgdG8gbm9uLXdhaXRp bmcgc3RhdHVzICovCiAJCQlpZiAobmV3X3N0YXR1cykKIAkJCXsKQEAgLTM5MDEsNyArMzkx MCw3IEBAIExvY2tCdWZmZXJGb3JDbGVhbnVwKEJ1ZmZlciBidWZmZXIpCiAJCQkJCQkJCQkJ CSAgIERlYWRsb2NrVGltZW91dCkpCiAJCQkJewogCQkJCQlMb2dSZWNvdmVyeUNvbmZsaWN0 KFBST0NTSUdfUkVDT1ZFUllfQ09ORkxJQ1RfQlVGRkVSUElOLAotCQkJCQkJCQkJCXdhaXRT dGFydCwgbm93LCBOVUxMKTsKKwkJCQkJCQkJCQl3YWl0U3RhcnQsIG5vdywgTlVMTCwgdHJ1 ZSk7CiAJCQkJCWxvZ2dlZF9yZWNvdmVyeV9jb25mbGljdCA9IHRydWU7CiAJCQkJfQogCQkJ fQpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvc3RhbmRieS5jIGIvc3Jj L2JhY2tlbmQvc3RvcmFnZS9pcGMvc3RhbmRieS5jCmluZGV4IGNmNGU2MzBhYTIuLjVkYjIz YzM2ZDEgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3N0b3JhZ2UvaXBjL3N0YW5kYnkuYwor KysgYi9zcmMvYmFja2VuZC9zdG9yYWdlL2lwYy9zdGFuZGJ5LmMKQEAgLTIyMywxMSArMjIz LDE0IEBAIFdhaXRFeGNlZWRzTWF4U3RhbmRieURlbGF5KHVpbnQzMiB3YWl0X2V2ZW50X2lu Zm8pCiAgKiB3YWl0X3N0YXJ0IGlzIHRoZSB0aW1lc3RhbXAgd2hlbiB0aGUgY2FsbGVyIHN0 YXJ0ZWQgdG8gd2FpdC4KICAqIG5vdyBpcyB0aGUgdGltZXN0YW1wIHdoZW4gdGhpcyBmdW5j dGlvbiBoYXMgYmVlbiBjYWxsZWQuCiAgKiB3YWl0X2xpc3QgaXMgdGhlIGxpc3Qgb2Ygdmly dHVhbCB0cmFuc2FjdGlvbiBpZHMgYXNzaWduZWQgdG8KLSAqIGNvbmZsaWN0aW5nIHByb2Nl c3Nlcy4KKyAqIGNvbmZsaWN0aW5nIHByb2Nlc3Nlcy4gc3RpbGxfd2FpdGluZyBpbmRpY2F0 ZXMgd2hldGhlcgorICogdGhlIHN0YXJ0dXAgcHJvY2VzcyBpcyBzdGlsbCB3YWl0aW5nIGZv ciB0aGUgcmVjb3ZlcnkgY29uZmxpY3QKKyAqIHRvIGJlIHJlc29sdmVkIG9yIG5vdC4KICAq Lwogdm9pZAogTG9nUmVjb3ZlcnlDb25mbGljdChQcm9jU2lnbmFsUmVhc29uIHJlYXNvbiwg VGltZXN0YW1wVHogd2FpdF9zdGFydCwKLQkJCQkJVGltZXN0YW1wVHogbm93LCBWaXJ0dWFs VHJhbnNhY3Rpb25JZCAqd2FpdF9saXN0KQorCQkJCQlUaW1lc3RhbXBUeiBub3csIFZpcnR1 YWxUcmFuc2FjdGlvbklkICp3YWl0X2xpc3QsCisJCQkJCWJvb2wgc3RpbGxfd2FpdGluZykK IHsKIAlsb25nCQlzZWNzOwogCWludAkJCXVzZWNzOwpAQCAtMjM1LDYgKzIzOCwxMiBAQCBM b2dSZWNvdmVyeUNvbmZsaWN0KFByb2NTaWduYWxSZWFzb24gcmVhc29uLCBUaW1lc3RhbXBU eiB3YWl0X3N0YXJ0LAogCVN0cmluZ0luZm9EYXRhIGJ1ZjsKIAlpbnQJCQlucHJvY3MgPSAw OwogCisJLyoKKwkgKiBUaGVyZSBtdXN0IGJlIG5vIGNvbmZsaWN0aW5nIHByb2Nlc3NlcyB3 aGVuIHRoZSByZWNvdmVyeSBjb25mbGljdCBoYXMKKwkgKiBhbHJlYWR5IGJlZW4gcmVzb2x2 ZWQuCisJICovCisJQXNzZXJ0KHN0aWxsX3dhaXRpbmcgfHwgd2FpdF9saXN0ID09IE5VTEwp OworCiAJVGltZXN0YW1wRGlmZmVyZW5jZSh3YWl0X3N0YXJ0LCBub3csICZzZWNzLCAmdXNl Y3MpOwogCW1zZWNzID0gc2VjcyAqIDEwMDAgKyB1c2VjcyAvIDEwMDA7CiAJdXNlY3MgPSB1 c2VjcyAlIDEwMDA7CkBAIC0yNzIsMTIgKzI4MSwyMSBAQCBMb2dSZWNvdmVyeUNvbmZsaWN0 KFByb2NTaWduYWxSZWFzb24gcmVhc29uLCBUaW1lc3RhbXBUeiB3YWl0X3N0YXJ0LAogCSAq IGNvbmZsaWN0aW5nIGJhY2tlbmRzIGluIGEgZGV0YWlsIG1lc3NhZ2UuIE5vdGUgdGhhdCBp ZiBhbGwgdGhlIGJhY2tlbmRzCiAJICogaW4gdGhlIGxpc3QgYXJlIG5vdCBhY3RpdmUsIG5v IGRldGFpbCBtZXNzYWdlIGlzIGxvZ2dlZC4KIAkgKi8KLQllcmVwb3J0KExPRywKLQkJCWVy cm1zZygicmVjb3Zlcnkgc3RpbGwgd2FpdGluZyBhZnRlciAlbGQuJTAzZCBtczogJXMiLAot CQkJCSAgIG1zZWNzLCB1c2VjcywgXyhnZXRfcmVjb3ZlcnlfY29uZmxpY3RfZGVzYyhyZWFz b24pKSksCi0JCQlucHJvY3MgPiAwID8gZXJyZGV0YWlsX2xvZ19wbHVyYWwoIkNvbmZsaWN0 aW5nIHByb2Nlc3M6ICVzLiIsCi0JCQkJCQkJCQkJCSAgIkNvbmZsaWN0aW5nIHByb2Nlc3Nl czogJXMuIiwKLQkJCQkJCQkJCQkJICBucHJvY3MsIGJ1Zi5kYXRhKSA6IDApOworCWlmIChz dGlsbF93YWl0aW5nKQorCXsKKwkJZXJlcG9ydChMT0csCisJCQkJZXJybXNnKCJyZWNvdmVy eSBzdGlsbCB3YWl0aW5nIGFmdGVyICVsZC4lMDNkIG1zOiAlcyIsCisJCQkJCSAgIG1zZWNz LCB1c2VjcywgXyhnZXRfcmVjb3ZlcnlfY29uZmxpY3RfZGVzYyhyZWFzb24pKSksCisJCQkJ bnByb2NzID4gMCA/IGVycmRldGFpbF9sb2dfcGx1cmFsKCJDb25mbGljdGluZyBwcm9jZXNz OiAlcy4iLAorCQkJCQkJCQkJCQkJICAiQ29uZmxpY3RpbmcgcHJvY2Vzc2VzOiAlcy4iLAor CQkJCQkJCQkJCQkJICBucHJvY3MsIGJ1Zi5kYXRhKSA6IDApOworCX0KKwllbHNlCisJewor CQllcmVwb3J0KExPRywKKwkJCQllcnJtc2coInJlY292ZXJ5IGZpbmlzaGVkIHdhaXRpbmcg YWZ0ZXIgJWxkLiUwM2QgbXM6ICVzIiwKKwkJCQkJICAgbXNlY3MsIHVzZWNzLCBfKGdldF9y ZWNvdmVyeV9jb25mbGljdF9kZXNjKHJlYXNvbikpKSk7CisJfQogCiAJaWYgKG5wcm9jcyA+ IDApCiAJCXBmcmVlKGJ1Zi5kYXRhKTsKQEAgLTM3MiwxMyArMzkwLDEyIEBAIFJlc29sdmVS ZWNvdmVyeUNvbmZsaWN0V2l0aFZpcnR1YWxYSURzKFZpcnR1YWxUcmFuc2FjdGlvbklkICp3 YWl0bGlzdCwKIAogCQkJCS8qCiAJCQkJICogRW1pdCB0aGUgbG9nIG1lc3NhZ2UgaWYgdGhl IHN0YXJ0dXAgcHJvY2VzcyBpcyB3YWl0aW5nCi0JCQkJICogbG9uZ2VyIHRoYW4gZGVhZGxv Y2tfdGltZW91dCBmb3IgcmVjb3ZlcnkgY29uZmxpY3Qgb24KLQkJCQkgKiBidWZmZXIgcGlu LgorCQkJCSAqIGxvbmdlciB0aGFuIGRlYWRsb2NrX3RpbWVvdXQgZm9yIHJlY292ZXJ5IGNv bmZsaWN0LgogCQkJCSAqLwogCQkJCWlmIChtYXliZV9sb2dfY29uZmxpY3QgJiYKIAkJCQkJ VGltZXN0YW1wRGlmZmVyZW5jZUV4Y2VlZHMod2FpdFN0YXJ0LCBub3csIERlYWRsb2NrVGlt ZW91dCkpCiAJCQkJewotCQkJCQlMb2dSZWNvdmVyeUNvbmZsaWN0KHJlYXNvbiwgd2FpdFN0 YXJ0LCBub3csIHdhaXRsaXN0KTsKKwkJCQkJTG9nUmVjb3ZlcnlDb25mbGljdChyZWFzb24s IHdhaXRTdGFydCwgbm93LCB3YWl0bGlzdCwgdHJ1ZSk7CiAJCQkJCWxvZ2dlZF9yZWNvdmVy eV9jb25mbGljdCA9IHRydWU7CiAJCQkJfQogCQkJfQpAQCAtMzg4LDYgKzQwNSwxNCBAQCBS ZXNvbHZlUmVjb3ZlcnlDb25mbGljdFdpdGhWaXJ0dWFsWElEcyhWaXJ0dWFsVHJhbnNhY3Rp b25JZCAqd2FpdGxpc3QsCiAJCXdhaXRsaXN0Kys7CiAJfQogCisJLyoKKwkgKiBFbWl0IHRo ZSBsb2cgbWVzc2FnZSBpZiByZWNvdmVyeSBjb25mbGljdCB3YXMgcmVzb2x2ZWQgYnV0IHRo ZSBzdGFydHVwCisJICogcHJvY2VzcyB3YWl0ZWQgbG9uZ2VyIHRoYW4gZGVhZGxvY2tfdGlt ZW91dCBmb3IgaXQuCisJICovCisJaWYgKGxvZ2dlZF9yZWNvdmVyeV9jb25mbGljdCkKKwkJ TG9nUmVjb3ZlcnlDb25mbGljdChyZWFzb24sIHdhaXRTdGFydCwgR2V0Q3VycmVudFRpbWVz dGFtcCgpLAorCQkJCQkJCU5VTEwsIGZhbHNlKTsKKwogCS8qIFJlc2V0IHBzIGRpc3BsYXkg aWYgd2UgY2hhbmdlZCBpdCAqLwogCWlmIChuZXdfc3RhdHVzKQogCXsKZGlmZiAtLWdpdCBh L3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1nci9wcm9jLmMgYi9zcmMvYmFja2VuZC9zdG9yYWdl L2xtZ3IvcHJvYy5jCmluZGV4IDUyN2UzOGM5NzQuLjg2NzFjOWRjMTAgMTAwNjQ0Ci0tLSBh L3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1nci9wcm9jLmMKKysrIGIvc3JjL2JhY2tlbmQvc3Rv cmFnZS9sbWdyL3Byb2MuYwpAQCAtMTMyNyw3ICsxMzI3LDggQEAgUHJvY1NsZWVwKExPQ0FM TE9DSyAqbG9jYWxsb2NrLCBMb2NrTWV0aG9kIGxvY2tNZXRob2RUYWJsZSkKIAkJCQkJICog bG9uZ2VyIHRoYW4gZGVhZGxvY2tfdGltZW91dC4KIAkJCQkJICovCiAJCQkJCUxvZ1JlY292 ZXJ5Q29uZmxpY3QoUFJPQ1NJR19SRUNPVkVSWV9DT05GTElDVF9MT0NLLAotCQkJCQkJCQkJ CXN0YW5kYnlXYWl0U3RhcnQsIG5vdywgY250ID4gMCA/IHZ4aWRzIDogTlVMTCk7CisJCQkJ CQkJCQkJc3RhbmRieVdhaXRTdGFydCwgbm93LAorCQkJCQkJCQkJCWNudCA+IDAgPyB2eGlk cyA6IE5VTEwsIHRydWUpOwogCQkJCQlsb2dnZWRfcmVjb3ZlcnlfY29uZmxpY3QgPSB0cnVl OwogCQkJCX0KIAkJCX0KQEAgLTE2MTIsNiArMTYxMywxNSBAQCBQcm9jU2xlZXAoTE9DQUxM T0NLICpsb2NhbGxvY2ssIExvY2tNZXRob2QgbG9ja01ldGhvZFRhYmxlKQogCQkJZGlzYWJs ZV90aW1lb3V0KERFQURMT0NLX1RJTUVPVVQsIGZhbHNlKTsKIAl9CiAKKwkvKgorCSAqIEVt aXQgdGhlIGxvZyBtZXNzYWdlIGlmIHJlY292ZXJ5IGNvbmZsaWN0IG9uIGxvY2sgd2FzIHJl c29sdmVkCisJICogYnV0IHRoZSBzdGFydHVwIHByb2Nlc3Mgd2FpdGVkIGxvbmdlciB0aGFu IGRlYWRsb2NrX3RpbWVvdXQgZm9yIGl0LgorCSAqLworCWlmIChsb2dnZWRfcmVjb3Zlcnlf Y29uZmxpY3QgJiYgbXlXYWl0U3RhdHVzID09IFBST0NfV0FJVF9TVEFUVVNfT0spCisJCUxv Z1JlY292ZXJ5Q29uZmxpY3QoUFJPQ1NJR19SRUNPVkVSWV9DT05GTElDVF9MT0NLLAorCQkJ CQkJCXN0YW5kYnlXYWl0U3RhcnQsIEdldEN1cnJlbnRUaW1lc3RhbXAoKSwKKwkJCQkJCQlO VUxMLCBmYWxzZSk7CisKIAkvKgogCSAqIFJlLWFjcXVpcmUgdGhlIGxvY2sgdGFibGUncyBw YXJ0aXRpb24gbG9jay4gIFdlIGhhdmUgdG8gZG8gdGhpcyB0byBob2xkCiAJICogb2ZmIGNh bmNlbC9kaWUgaW50ZXJydXB0cyBiZWZvcmUgd2UgY2FuIG1lc3Mgd2l0aCBsb2NrQXdhaXRl ZCAoZWxzZSB3ZQpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvc3RvcmFnZS9zdGFuZGJ5Lmgg Yi9zcmMvaW5jbHVkZS9zdG9yYWdlL3N0YW5kYnkuaAppbmRleCA3NmNjZDhjZGU0Li4xNzY2 MmY2ZmQ3IDEwMDY0NAotLS0gYS9zcmMvaW5jbHVkZS9zdG9yYWdlL3N0YW5kYnkuaAorKysg Yi9zcmMvaW5jbHVkZS9zdG9yYWdlL3N0YW5kYnkuaApAQCAtNDAsNyArNDAsOCBAQCBleHRl cm4gdm9pZCBTdGFuZGJ5RGVhZExvY2tIYW5kbGVyKHZvaWQpOwogZXh0ZXJuIHZvaWQgU3Rh bmRieVRpbWVvdXRIYW5kbGVyKHZvaWQpOwogZXh0ZXJuIHZvaWQgU3RhbmRieUxvY2tUaW1l b3V0SGFuZGxlcih2b2lkKTsKIGV4dGVybiB2b2lkIExvZ1JlY292ZXJ5Q29uZmxpY3QoUHJv Y1NpZ25hbFJlYXNvbiByZWFzb24sIFRpbWVzdGFtcFR6IHdhaXRfc3RhcnQsCi0JCQkJCQkJ CVRpbWVzdGFtcFR6IGN1cl90cywgVmlydHVhbFRyYW5zYWN0aW9uSWQgKndhaXRfbGlzdCk7 CisJCQkJCQkJCVRpbWVzdGFtcFR6IGN1cl90cywgVmlydHVhbFRyYW5zYWN0aW9uSWQgKndh aXRfbGlzdCwKKwkJCQkJCQkJYm9vbCBzdGlsbF93YWl0aW5nKTsKIAogLyoKICAqIFN0YW5k YnkgUm1nciAoUk1fU1RBTkRCWV9JRCkK --------------DF2A51BA6B21302B26FE2FDF--