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 1s2akM-004Kdq-8g for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 18:01:30 +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 1s2akJ-002qBU-DE for pgsql-bugs@arkaria.postgresql.org; Thu, 02 May 2024 18:01:28 +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 1s2akI-002qBM-SJ for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 18:01:28 +0000 Received: from forward500a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d500]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2akE-001D2v-RT for pgsql-bugs@lists.postgresql.org; Thu, 02 May 2024 18:01:27 +0000 Received: from mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:3d80:0:640:1395:0]) by forward500a.mail.yandex.net (Yandex) with ESMTPS id B614361268; Thu, 2 May 2024 21:01:17 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id E1Yvjp1a4W20-83MjGwk6; Thu, 02 May 2024 21:01:17 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1714672877; bh=7BaEHlaH8cEXUjdsxYd4RduJ0+Y9sZtKMCZjc/30Mzg=; h=In-Reply-To:Cc:Date:References:To:Subject:Message-ID:From; b=Y2tzbegvRpA0WNn7M2CHROmteKERSz4bKUyy1zmQktqp1+uD5bP4b4p4N/aajSYbp 0y66grg9uZecyQYEt4HQEIv3PA6k0ods2gXbLT3dYkmF46wdxq95eM/28H6u/fSZHq j5qQvX0BgFhz81fEgvveBn2H/88EjPibM5+I2uMU= Authentication-Results: mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Content-Type: multipart/mixed; boundary="------------kLHR8UTLORSKO0kIm4g8YQ7y" Message-ID: Date: Thu, 2 May 2024 21:01:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() To: Peter Geoghegan , Melanie Plageman Cc: Andres Freund , Noah Misch , Robert Haas , Matthias van de Meent , Alexander Lakhin , PostgreSQL mailing lists References: <17257-1e46de26bec11433@postgresql.org> <20231225024402.77@rfd.leadboat.com> <20240106202413.e5@rfd.leadboat.com> <20240415173913.4zyyrwaftujxthf2@awork3.anarazel.de> Content-Language: en-US From: Alena Rybakina In-Reply-To: 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. --------------kLHR8UTLORSKO0kIm4g8YQ7y Content-Type: multipart/alternative; boundary="------------tuyx1BMo3Y2tVRjXUNKDWF8Q" --------------tuyx1BMo3Y2tVRjXUNKDWF8Q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02.05.2024 19:52, Peter Geoghegan wrote: > On Sat, Apr 27, 2024 at 10:38 AM Melanie Plageman > wrote: >> In 17, we don't ever get a new HTSV_Result, so if the tuple is not >> removed, it would be because HeapTupleSatisfiesVacuumHorizon() >> returned HEAPTUPLE_RECENTLY_DEAD and, if GlobalVisTestIsRemovableXid() >> was called, dead_after did not precede GlobalVisState->maybe_needed. >> This tuple, during this vacuum of the relation, would never be >> determined to be HEAPTUPLE_DEAD or it would have been removed. > That makes sense. > >>>> It will always be HEAPTUPLE_RECENTLY_DEAD in 17 and in <= 16, if >>>> HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DEAD, we wouldn't call >>>> heap_prepare_freeze_tuple() because of the retry loop. >>> The retry loop exists precisely because heap_prepare_freeze_tuple() >>> isn't prepared to deal with HEAPTUPLE_DEAD tuples. So I agree that >>> that won't be allowed to happen on versions that have the retry loop >>> (14 - 16). >> So, it can't happen in back branches. Let's just address 17. Help me >> understand how this can happen in 17. > Just to be clear, I never said that it was possible in 17. If I > somehow implied it, then I didn't mean to. > Hi! I also investigated this issue and reproduced it using this test added to the isolated tests, where I added 2 tuples, deleted them and ran vacuum and printed the tuple_deleted and dead_tuples statistics (I attached test c to this email as a patch). Within400iterationsormore, Igotthe results: n_dead_tup|n_live_tup|n_tup_del ----------------+------------+------------- 0| 0| 0 (1 row) After 400 or more running cycles, I felt the differences, as shown earlier:  n_dead_tup|n_live_tup|n_tup_del  ----------+----------+--------- -         0|         0|        0 +         2|         0|        0  (1 row) I debugged and found that the test produces results with 0 dead tuples if GlobalVisTempRels.maybe_needed is less than the x_max of the tuple. In the code, this condition works in heap_prune_satisfies_vacuum: else if (GlobalVisTestIsRemovableXid(prstate->vistest, dead_after)) {      res = HEAPTUPLE_DEAD; } But when GlobalVisTempRels.maybe_needed is equal to the x_max xid of the tuple, vacuum does not touch this tuple, because the heap_prune_satisfies_vacuum function returns the status of the RECENTLY_DEAD tuple. Unfortunately, I have not found any explanation why GlobalVisTempRels.maybe_needed does not change after 400 iterations or more. I'm still studying it. Perhaps this information will help you. I reproduced the problem on REL_16_STABLE. -- Regards, Alena Rybakina Postgres Professional:http://www.postgrespro.com The Russian Postgres Company --------------tuyx1BMo3Y2tVRjXUNKDWF8Q Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.05.2024 19:52, Peter Geoghegan wrote:
On Sat, Apr 27, 2024 at 10:38 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:

In 17, we don't ever get a new HTSV_Result, so if the tuple is not
removed, it would be because HeapTupleSatisfiesVacuumHorizon()
returned HEAPTUPLE_RECENTLY_DEAD and, if GlobalVisTestIsRemovableXid()
was called, dead_after did not precede GlobalVisState->maybe_needed.
This tuple, during this vacuum of the relation, would never be
determined to be HEAPTUPLE_DEAD or it would have been removed.

That makes sense.


It will always be HEAPTUPLE_RECENTLY_DEAD in 17 and in <= 16, if
HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DEAD, we wouldn't call
heap_prepare_freeze_tuple() because of the retry loop.

The retry loop exists precisely because heap_prepare_freeze_tuple()
isn't prepared to deal with HEAPTUPLE_DEAD tuples. So I agree that
that won't be allowed to happen on versions that have the retry loop
(14 - 16).

So, it can't happen in back branches. Let's just address 17. Help me
understand how this can happen in 17.

Just to be clear, I never said that it was possible in 17. If I
somehow implied it, then I didn't mean to.
Hi! I also investigated this issue and reproduced it using this test added to the isolated tests, where I added 2 tuples, deleted them and ran vacuum and printed the tuple_deleted and dead_tuples statistics (I attached test c to this email as a patch). Within 400 iterations or more, I got the results:

n_dead_tup|n_live_tup|n_tup_del ----------------+------------+------------- 0| 0| 0 (1 row)

After 400 or more running cycles, I felt the differences, as shown earlier:

 n_dead_tup|n_live_tup|n_tup_del
 ----------+----------+---------
-         0|         0|        0
+         2|         0|        0
 (1 row)


I debugged and found that the test produces results with 0 dead tuples if GlobalVisTempRels.maybe_needed is less than the x_max of the tuple. In the code, this condition works in heap_prune_satisfies_vacuum:

else if (GlobalVisTestIsRemovableXid(prstate->vistest, dead_after))
{
     res = HEAPTUPLE_DEAD;
}

But when GlobalVisTempRels.maybe_needed is equal to the x_max xid of the tuple, vacuum does not touch this tuple, because the heap_prune_satisfies_vacuum function returns the status of the RECENTLY_DEAD tuple.

Unfortunately, I have not found any explanation why GlobalVisTempRels.maybe_needed does not change after 400 iterations or more. I'm still studying it. Perhaps this information will help you.

I reproduced the problem on REL_16_STABLE. 

-- 
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--------------tuyx1BMo3Y2tVRjXUNKDWF8Q-- --------------kLHR8UTLORSKO0kIm4g8YQ7y Content-Type: text/x-patch; charset=UTF-8; name="0001-vacuum_test.patch" Content-Disposition: attachment; filename="0001-vacuum_test.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy90ZXN0L2lzb2xhdGlvbi9leHBlY3RlZC92YWN1dW1fdGVzdC5v dXQgYi9zcmMvdGVzdC9pc29sYXRpb24vZXhwZWN0ZWQvdmFjdXVtX3Rlc3Qub3V0Cm5ldyBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi4zOGVmMWU2OGI1ZAotLS0gL2Rl di9udWxsCisrKyBiL3NyYy90ZXN0L2lzb2xhdGlvbi9leHBlY3RlZC92YWN1dW1fdGVzdC5v dXQKQEAgLTAsMCArMSwyMyBAQAordW51c2VkIHN0ZXAgbmFtZTogczFfYWN0aXZpdHlfcHJp bnQKK3VudXNlZCBzdGVwIG5hbWU6IHMxX2RlbGV0ZV9oYWxmX3RhYmxlCit1bnVzZWQgc3Rl cCBuYW1lOiBzMV9zZXRfYWdyZXNzaXZlX3ZhY3V1bQordW51c2VkIHN0ZXAgbmFtZTogczFf dXBkYXRlCit1bnVzZWQgc3RlcCBuYW1lOiBzMV92YWN1dW0KK3VudXNlZCBzdGVwIG5hbWU6 IHMxX3ZhY3V1bV9mdWxsCitQYXJzZWQgdGVzdCBzcGVjIHdpdGggMSBzZXNzaW9ucworCitz dGFydGluZyBwZXJtdXRhdGlvbjogczFfaW5zZXJ0IHMxX2RlbGV0ZV9mdWxsX3RhYmxlIHMx X3ZhY3V1bV9wYXJhbGxlbCBzMV9wcmludF92YWN1dW1fc3RhdHNfdGFibGVzCitzdGVwIHMx X2luc2VydDogSU5TRVJUIElOVE8gdmVzdGF0KHgpIFNFTEVDVCBpZCBGUk9NIGdlbmVyYXRl X3NlcmllcygxLDIpIEFzIGlkOworc3RlcCBzMV9kZWxldGVfZnVsbF90YWJsZTogREVMRVRF IEZST00gdmVzdGF0Oworc3RlcCBzMV92YWN1dW1fcGFyYWxsZWw6IFZBQ1VVTSAoUEFSQUxM RUwgMiwgSU5ERVhfQ0xFQU5VUCBPTikgdmVzdGF0Oworc3RlcCBzMV9wcmludF92YWN1dW1f c3RhdHNfdGFibGVzOiAKKyAgICBTRUxFQ1Qgbl9kZWFkX3R1cCwgbl9saXZlX3R1cCwgbl90 dXBfZGVsCisgICAgRlJPTSBwZ19zdGF0X2FsbF90YWJsZXMgdnQsIHBnX2NsYXNzIGMKKyAg ICBXSEVSRSB2dC5yZWxuYW1lID0gJ3Zlc3RhdCcgQU5ECisgICAgICAgICAgdnQucmVsaWQg PSBjLm9pZDsKKworbl9kZWFkX3R1cHxuX2xpdmVfdHVwfG5fdHVwX2RlbAorLS0tLS0tLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLQorICAgICAgICAgMHwgICAgICAgICAwfCAgICAgICAg MAorKDEgcm93KQorCmRpZmYgLS1naXQgYS9zcmMvdGVzdC9pc29sYXRpb24vaXNvbGF0aW9u X3NjaGVkdWxlIGIvc3JjL3Rlc3QvaXNvbGF0aW9uL2lzb2xhdGlvbl9zY2hlZHVsZQppbmRl eCAwMzQyZWIzOWU0MC4uZWRiNzUxYzJmZjQgMTAwNjQ0Ci0tLSBhL3NyYy90ZXN0L2lzb2xh dGlvbi9pc29sYXRpb25fc2NoZWR1bGUKKysrIGIvc3JjL3Rlc3QvaXNvbGF0aW9uL2lzb2xh dGlvbl9zY2hlZHVsZQpAQCAtMSwxMTYgKzEgQEAKLXRlc3Q6IHJlYWQtb25seS1hbm9tYWx5 Ci10ZXN0OiByZWFkLW9ubHktYW5vbWFseS0yCi10ZXN0OiByZWFkLW9ubHktYW5vbWFseS0z Ci10ZXN0OiByZWFkLXdyaXRlLXVuaXF1ZQotdGVzdDogcmVhZC13cml0ZS11bmlxdWUtMgot dGVzdDogcmVhZC13cml0ZS11bmlxdWUtMwotdGVzdDogcmVhZC13cml0ZS11bmlxdWUtNAot dGVzdDogc2ltcGxlLXdyaXRlLXNrZXcKLXRlc3Q6IHJlY2VpcHQtcmVwb3J0Ci10ZXN0OiB0 ZW1wb3JhbC1yYW5nZS1pbnRlZ3JpdHkKLXRlc3Q6IHByb2plY3QtbWFuYWdlcgotdGVzdDog Y2xhc3Nyb29tLXNjaGVkdWxpbmcKLXRlc3Q6IHRvdGFsLWNhc2gKLXRlc3Q6IHJlZmVyZW50 aWFsLWludGVncml0eQotdGVzdDogcmktdHJpZ2dlcgotdGVzdDogcGFydGlhbC1pbmRleAot dGVzdDogdHdvLWlkcwotdGVzdDogbXVsdGlwbGUtcm93LXZlcnNpb25zCi10ZXN0OiBpbmRl eC1vbmx5LXNjYW4KLXRlc3Q6IHByZWRpY2F0ZS1sb2NrLWhvdC10dXBsZQotdGVzdDogdXBk YXRlLWNvbmZsaWN0LW91dAotdGVzdDogZGVhZGxvY2stc2ltcGxlCi10ZXN0OiBkZWFkbG9j ay1oYXJkCi10ZXN0OiBkZWFkbG9jay1zb2Z0Ci10ZXN0OiBkZWFkbG9jay1zb2Z0LTIKLXRl c3Q6IGRlYWRsb2NrLXBhcmFsbGVsCi10ZXN0OiBkZXRhY2gtcGFydGl0aW9uLWNvbmN1cnJl bnRseS0xCi10ZXN0OiBkZXRhY2gtcGFydGl0aW9uLWNvbmN1cnJlbnRseS0yCi10ZXN0OiBk ZXRhY2gtcGFydGl0aW9uLWNvbmN1cnJlbnRseS0zCi10ZXN0OiBkZXRhY2gtcGFydGl0aW9u LWNvbmN1cnJlbnRseS00Ci10ZXN0OiBmay1jb250ZW50aW9uCi10ZXN0OiBmay1kZWFkbG9j awotdGVzdDogZmstZGVhZGxvY2syCi10ZXN0OiBmay1wYXJ0aXRpb25lZC0xCi10ZXN0OiBm ay1wYXJ0aXRpb25lZC0yCi10ZXN0OiBmay1zbmFwc2hvdAotdGVzdDogc3VieGlkLW92ZXJm bG93Ci10ZXN0OiBldmFsLXBsYW4tcXVhbAotdGVzdDogZXZhbC1wbGFuLXF1YWwtdHJpZ2dl cgotdGVzdDogbG9jay11cGRhdGUtZGVsZXRlCi10ZXN0OiBsb2NrLXVwZGF0ZS10cmF2ZXJz YWwKLXRlc3Q6IGluaGVyaXQtdGVtcAotdGVzdDogdGVtcC1zY2hlbWEtY2xlYW51cAotdGVz dDogaW5zZXJ0LWNvbmZsaWN0LWRvLW5vdGhpbmcKLXRlc3Q6IGluc2VydC1jb25mbGljdC1k by1ub3RoaW5nLTIKLXRlc3Q6IGluc2VydC1jb25mbGljdC1kby11cGRhdGUKLXRlc3Q6IGlu c2VydC1jb25mbGljdC1kby11cGRhdGUtMgotdGVzdDogaW5zZXJ0LWNvbmZsaWN0LWRvLXVw ZGF0ZS0zCi10ZXN0OiBpbnNlcnQtY29uZmxpY3Qtc3BlY2NvbmZsaWN0Ci10ZXN0OiBtZXJn ZS1pbnNlcnQtdXBkYXRlCi10ZXN0OiBtZXJnZS1kZWxldGUKLXRlc3Q6IG1lcmdlLXVwZGF0 ZQotdGVzdDogbWVyZ2UtbWF0Y2gtcmVjaGVjawotdGVzdDogbWVyZ2Utam9pbgotdGVzdDog ZGVsZXRlLWFib3J0LXNhdmVwdAotdGVzdDogZGVsZXRlLWFib3J0LXNhdmVwdC0yCi10ZXN0 OiBhYm9ydGVkLWtleXJldm9rZQotdGVzdDogbXVsdGl4YWN0LW5vLWRlYWRsb2NrCi10ZXN0 OiBtdWx0aXhhY3Qtbm8tZm9yZ2V0Ci10ZXN0OiBsb2NrLWNvbW1pdHRlZC11cGRhdGUKLXRl c3Q6IGxvY2stY29tbWl0dGVkLWtleXVwZGF0ZQotdGVzdDogdXBkYXRlLWxvY2tlZC10dXBs ZQotdGVzdDogcmVpbmRleC1jb25jdXJyZW50bHkKLXRlc3Q6IHJlaW5kZXgtY29uY3VycmVu dGx5LXRvYXN0Ci10ZXN0OiByZWluZGV4LXNjaGVtYQotdGVzdDogcHJvcGFnYXRlLWxvY2st ZGVsZXRlCi10ZXN0OiB0dXBsZWxvY2stY29uZmxpY3QKLXRlc3Q6IHR1cGxlbG9jay11cGRh dGUKLXRlc3Q6IHR1cGxlbG9jay11cGdyYWRlLW5vLWRlYWRsb2NrCi10ZXN0OiB0dXBsZWxv Y2stcGFydGl0aW9uCi10ZXN0OiBmcmVlemUtdGhlLWRlYWQKLXRlc3Q6IG5vd2FpdAotdGVz dDogbm93YWl0LTIKLXRlc3Q6IG5vd2FpdC0zCi10ZXN0OiBub3dhaXQtNAotdGVzdDogbm93 YWl0LTUKLXRlc3Q6IHNraXAtbG9ja2VkCi10ZXN0OiBza2lwLWxvY2tlZC0yCi10ZXN0OiBz a2lwLWxvY2tlZC0zCi10ZXN0OiBza2lwLWxvY2tlZC00Ci10ZXN0OiBkcm9wLWluZGV4LWNv bmN1cnJlbnRseS0xCi10ZXN0OiBtdWx0aXBsZS1jaWMKLXRlc3Q6IGFsdGVyLXRhYmxlLTEK LXRlc3Q6IGFsdGVyLXRhYmxlLTIKLXRlc3Q6IGFsdGVyLXRhYmxlLTMKLXRlc3Q6IGFsdGVy LXRhYmxlLTQKLXRlc3Q6IGNyZWF0ZS10cmlnZ2VyCi10ZXN0OiBzZXF1ZW5jZS1kZGwKLXRl c3Q6IGFzeW5jLW5vdGlmeQotdGVzdDogdmFjdXVtLW5vLWNsZWFudXAtbG9jawotdGVzdDog dGltZW91dHMKLXRlc3Q6IHZhY3V1bS1jb25jdXJyZW50LWRyb3AKLXRlc3Q6IHZhY3V1bS1j b25mbGljdAotdGVzdDogdmFjdXVtLXNraXAtbG9ja2VkCi10ZXN0OiBzdGF0cwotdGVzdDog aG9yaXpvbnMKLXRlc3Q6IHByZWRpY2F0ZS1oYXNoCi10ZXN0OiBwcmVkaWNhdGUtZ2lzdAot dGVzdDogcHJlZGljYXRlLWdpbgotdGVzdDogcGFydGl0aW9uLWNvbmN1cnJlbnQtYXR0YWNo Ci10ZXN0OiBwYXJ0aXRpb24tZHJvcC1pbmRleC1sb2NraW5nCi10ZXN0OiBwYXJ0aXRpb24t a2V5LXVwZGF0ZS0xCi10ZXN0OiBwYXJ0aXRpb24ta2V5LXVwZGF0ZS0yCi10ZXN0OiBwYXJ0 aXRpb24ta2V5LXVwZGF0ZS0zCi10ZXN0OiBwYXJ0aXRpb24ta2V5LXVwZGF0ZS00Ci10ZXN0 OiBwYXJ0aXRpb24tbWVyZ2UKLXRlc3Q6IHBhcnRpdGlvbi1zcGxpdAotdGVzdDogcGxwZ3Nx bC10b2FzdAotdGVzdDogY2x1c3Rlci1jb25mbGljdAotdGVzdDogY2x1c3Rlci1jb25mbGlj dC1wYXJ0aXRpb24KLXRlc3Q6IHRydW5jYXRlLWNvbmZsaWN0Ci10ZXN0OiBzZXJpYWxpemFi bGUtcGFyYWxsZWwKLXRlc3Q6IHNlcmlhbGl6YWJsZS1wYXJhbGxlbC0yCi10ZXN0OiBzZXJp YWxpemFibGUtcGFyYWxsZWwtMwotdGVzdDogbWF0dmlldy13cml0ZS1za2V3Ci10ZXN0OiBs b2NrLW5vd2FpdAordGVzdDogdmFjdXVtX3Rlc3QKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBm aWxlCmRpZmYgLS1naXQgYS9zcmMvdGVzdC9pc29sYXRpb24vc3BlY3MvdmFjdXVtX3Rlc3Qu c3BlYyBiL3NyYy90ZXN0L2lzb2xhdGlvbi9zcGVjcy92YWN1dW1fdGVzdC5zcGVjCm5ldyBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi4xZmI0ZDY3Y2MzNAotLS0gL2Rl di9udWxsCisrKyBiL3NyYy90ZXN0L2lzb2xhdGlvbi9zcGVjcy92YWN1dW1fdGVzdC5zcGVj CkBAIC0wLDAgKzEsMzQgQEAKK3NldHVwCit7CisgICAgQ1JFQVRFIFRBQkxFIHZlc3RhdCAo eCBpbnQgcHJpbWFyeSBrZXkpIFdJVEggKGF1dG92YWN1dW1fZW5hYmxlZCA9IG9mZik7CisK K30KKwordGVhcmRvd24KK3sKKyAgICBEUk9QIFRBQkxFIHZlc3RhdCBDQVNDQURFOworfQor CitzZXNzaW9uIHMxCitzdGVwIHMxX3NldF9hZ3Jlc3NpdmVfdmFjdXVtICAgIHsgU0VUIHZh Y3V1bV9mcmVlemVfbWluX2FnZSA9IDA7IH0KK3N0ZXAgczFfaW5zZXJ0ICAgICAgICAgICAg ICAgICAgeyBJTlNFUlQgSU5UTyB2ZXN0YXQoeCkgU0VMRUNUIGlkIEZST00gZ2VuZXJhdGVf c2VyaWVzKDEsMikgQXMgaWQ7IH0KK3N0ZXAgczFfdXBkYXRlICAgICAgICAgICAgICAgICAg eyBVUERBVEUgdmVzdGF0IFNFVCB4ID0geCsxOyB9CitzdGVwIHMxX2RlbGV0ZV9oYWxmX3Rh YmxlICAgICAgIHsgREVMRVRFIEZST00gdmVzdGF0IFdIRVJFIHggJSAyID0gMDsgfQorc3Rl cCBzMV9kZWxldGVfZnVsbF90YWJsZSAgICAgICB7IERFTEVURSBGUk9NIHZlc3RhdDsgfQor c3RlcCBzMV92YWN1dW0gICAgICAgICAgICAgICAgICB7IFZBQ1VVTSB2ZXN0YXQ7IH0KK3N0 ZXAgczFfdmFjdXVtX2Z1bGwgICAgICAgICAgICAgeyBWQUNVVU0gRlVMTCB2ZXN0YXQ7IH0K K3N0ZXAgczFfdmFjdXVtX3BhcmFsbGVsICAgICAgICAgeyBWQUNVVU0gKFBBUkFMTEVMIDIs IElOREVYX0NMRUFOVVAgT04pIHZlc3RhdDsgfQorc3RlcCBzMV9hY3Rpdml0eV9wcmludCAg ICAgICAgICB7IHNlbGVjdCBhcHBsaWNhdGlvbl9uYW1lLCBiYWNrZW5kX3R5cGUgZnJvbSAg cGdfc3RhdF9hY3Rpdml0eSBvcmRlciBieSAoYXBwbGljYXRpb25fbmFtZSwgYmFja2VuZF90 eXBlKTsgfQorc3RlcCBzMV9wcmludF92YWN1dW1fc3RhdHNfdGFibGVzCit7CisgICAgU0VM RUNUIG5fZGVhZF90dXAsIG5fbGl2ZV90dXAsIG5fdHVwX2RlbAorICAgIEZST00gcGdfc3Rh dF9hbGxfdGFibGVzIHZ0LCBwZ19jbGFzcyBjCisgICAgV0hFUkUgdnQucmVsbmFtZSA9ICd2 ZXN0YXQnIEFORAorICAgICAgICAgIHZ0LnJlbGlkID0gYy5vaWQ7Cit9CisKK3Blcm11dGF0 aW9uCisgICAgczFfaW5zZXJ0CisgICAgczFfZGVsZXRlX2Z1bGxfdGFibGUKKyAgICBzMV92 YWN1dW1fcGFyYWxsZWwKKyAgICBzMV9wcmludF92YWN1dW1fc3RhdHNfdGFibGVzClwgTm8g bmV3bGluZSBhdCBlbmQgb2YgZmlsZQotLSAKMi4zNC4xCgo= --------------kLHR8UTLORSKO0kIm4g8YQ7y--