Content-Type: multipart/mixed; boundary="------------ngqZY0dfHsEhC1M53tJJfux7"
Message-ID: <f0631dfa-0158-472b-8d6f-95728a5865a9@garret.ru>
Date: Mon, 29 Dec 2025 18:34:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: index prefetching
To: Tomas Vondra <tomas@vondra.me>, Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro
 <thomas.munro@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Melanie Plageman <melanieplageman@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Georgios <gkokolatos@protonmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
References: <6d59c277-c440-4d1f-a46e-157958c06a5f@vondra.me>
 <4zeu5yb73byiquvf3eefsunnrydyqfxy3eup66jrliutrtd4xl@5iifjey4n5m5>
 <c515d037-9c9c-40d3-9f1f-f0e68bf5842b@vondra.me>
 <CAH2-WzkAC_gWQgc3MV3MWBx2EUaE4TfPk8XQPkJgs1R_qNvo=A@mail.gmail.com>
 <CAH2-WznLRnUZHC4kmR+J3MgGpN0iTUaZ-4xeSHPiaYR=y3C8Og@mail.gmail.com>
 <CAH2-WzkHK0++yn3_nmWL2rWzXiu8Qc=2=NPQDG4nfVjvYkRDrQ@mail.gmail.com>
 <CAH2-Wzk9=x=a2TbcqYcX+XXmDHQr5=1v9m4Z_v8a-KwF1Zoz0A@mail.gmail.com>
 <CAH2-WzmYqhacBH161peAWb5eF=Ja7CFAQ+0jSEMq=qnfLVTOOg@mail.gmail.com>
 <CAH2-Wzmm+mXuv_r+eYgcwOKZzNSmbYoEmxi5mdKMUtkmYa_qXw@mail.gmail.com>
 <CAH2-WzkC_EdGB_tdEQr63BiOuJbcvZiV=xO+OJYux4wOaxPD8w@mail.gmail.com>
 <CAH2-Wzn8whv-RE4E5L2WQB_Ha_jy0UReJq1yypu83gDYHeXq5g@mail.gmail.com>
 <CAH2-Wzm7-QuDOs6TcqfhhDsGEZCuHtn=D-SriOTnTZ_fiXNBvA@mail.gmail.com>
 <8f123089-49ed-4c35-ab28-e3df70d28043@garret.ru>
 <c2357c01-bf15-44d6-a4cb-591675457032@vondra.me>
 <69908539-3cc5-4572-b69f-055fa40d3bea@garret.ru>
 <95b6c6ef-4ba1-44f6-b1ac-eef0bbb5327a@vondra.me>
Content-Language: en-US
From: Konstantin Knizhnik <knizhnik@garret.ru>
In-Reply-To: <95b6c6ef-4ba1-44f6-b1ac-eef0bbb5327a@vondra.me>
Archived-At: 
 <https://www.postgresql.org/message-id/f0631dfa-0158-472b-8d6f-95728a5865a9%40garret.ru>
Precedence: bulk

This is a multi-part message in MIME format.
--------------ngqZY0dfHsEhC1M53tJJfux7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 29/12/2025 1:53 AM, Tomas Vondra wrote:
>
> On 12/28/25 21:30, Konstantin Knizhnik wrote:
>> On 28/12/2025 8:08 PM, Tomas Vondra wrote:
>>> On 12/25/25 16:39, Konstantin Knizhnik wrote:
>>>> On 21/12/2025 7:55 PM, Peter Geoghegan wrote:
>>>>> On Wed, Dec 10, 2025 at 9:21 PM Peter Geoghegan <pg@bowt.ie> wrote:
>>>>>> Attached is v4.
>>>>> Attached is v5. Changes from v4:
>>>>>
>>>>> * Simplified and optimized index-only scans, with a particular
>>>>> emphasis on avoiding regressions with nested loop joins with an inner
>>>>> index-only scan.
>>>>>
>>>>> There were quite a number of small problems/dead code related to
>>>>> index-only scans fixed by this new v5. Overall, I'm quite a bit
>>>>> happier with the state of index-only scans, which I'd not paid too
>>>>> much attention to before now.
>>>>>
>>>>> * Added Valgrind instrumentation to the hash index patch, which was
>>>>> required to fix some false positives.
>>>>>
>>>>> The generic indexam_util_batch_unlock routine had Valgrind
>>>>> instrumentation in earlier versions, just to keep nbtree's buffer
>>>>> locking checks from generating similar false positives. Some time
>>>>> later, when I added the hashgetbatch patch, there were new Valgrind
>>>>> false positives during hash index scans -- which I missed at first.
>>>>> This new v5 revisions adds similar Valgrind checks to hash itself
>>>>> (changes that add code that is more or less a direct port of the stuff
>>>>> added to nbtree by commit 4a70f829), which fixes the false positives,
>>>>> and is independently useful.
>>>>>
>>>>> The rule for amgetbatch-based index AMs is that they must have similar
>>>>> buffer locking instrumentation. That seems like a good thing.
>>>>>
>>>>> -- 
>>>>> Peter Geoghegan
>>>> I the previous mail I shared results of my experiments with different
>>>> prefetch distance.
>>>> I think that we should start prefetching of heap tuples not from the
>>>> second batch, but after some number of proceeded tids.
>>>>
>>>> Attached please find a patch which implements this approach.
>>>> And below are updated results:
>>>>
>>>> limit\prefetch    on      off   always  inc    threshold
>>>> 1                 12074   12765  3146    3282     12394
>>>> 2                 5912    6198   2463    2438      6124
>>>> 4                 2919    3047   1334    1964      2910
>>>> 8                 1554    1496   1166    1409      1588
>>>> 16                815     775    947     940        600
>>>> 32                424     403    687     695        478
>>>> 64                223     208    446     453        358
>>>> 128               115     106    258     270        232
>>>> 256               68      53     138     149        131
>>>> 512               43      27     72      78          71
>>>> 1024              28      13     38      40          38
>>>>
>>>> Last column is result of prefetch with read_stream_threshold=10.
>>>>
>>> That's great, but it only works for cases that can (and do) benefit from
>>> the prefetching. Try running the benchmark with a data set that fits
>>> into shared buffers (or RAM), which makes prefetching useless.
>>>
>>> I tried that with your test, comparing master, v5 and v5 + your
>>> read_stream_threshold patch. See the attached run.sh script, and the PDF
>>> summarizing the results. The last two column groups are comparisons to
>>> master, with green=improvement, red=regression. There are no actual
>>> improvements (1% delta is just noise). But the read_stream_threshold
>>> results have a clear pattern of pretty massive (20-30%) regressions.
>>>
>>> The difference between v5 and v5-threshold is pretty clear.
>>>
>>> IIRC cases like this are *exactly* why we ended up with the current
>>> heuristics, enabling prefetching only from the second batch. This
>>> removes the risk of expensive read_stream init for very fast queries
>>> that don't benefit anything. Of course, prefetching may be useless for
>>> later batches too (e.g. if all the data is cached), but the query will
>>> be expensive enough for the read_stream init cost to be negligible.
>>>
>>> To put this differently, the more aggressive the heuristics is (enabling
>>> prefetching in more case), the more likely it's to cause regressions.
>>> We've chosen to be more defensive, i.e. to sacrifice some possible gains
>>> in order to not regress plausible workloads. I hope we agree queries on
>>> fully cached "hot" data are pretty common / important.
>>>
>>> We can probably do better in the future. But we'll never know for sure
>>> if a given scan benefits from prefetching. It's not just about the
>>> number of items in the batch, but also about how many heap pages that
>>> translates to, what I/O pattern (random vs. sequential?), how many are
>>> already cached. For some queries we don't even know how many items we'll
>>> actually need. We can't check all that at the very beginning, because
>>> it's simply prohibitively expensive.
>>
>> I tried to reproduce your results, but at Mac I do not see some
>> noticeable difference  for 250k records, fillfactor=10 and 4GB shared
>> buffers
>> between `enable_indexscan_prefetch=false` and
>> `enable_indexscan_prefetch=true`.
>> I can't believe that just adding this checks in `heap_batch_advance_pos`
>> can cause 75% degrade of performance (because for limit < 10, no read
>> stream is initialized, but still we somewhere loose 25%).
>>
>> I just commented this fragment of code in heapam_handler.c:
>>
>>
>> #if 0
>>      proceed_items = ScanDirectionIsForward(direction)
>>          ? pos->item - batch->firstItem
>>          : batch->lastItem - pos->item;
>>      /* Delay initializing stream until proceeding */
>>      if (proceed_items >= read_stream_threshold
>>          && !scan->xs_heapfetch->rs
>>          && !scan->batchqueue->disabled
>>          && !scan->xs_want_itup    /* XXX prefetching disabled for IoS,
>> for now */
>>          && enable_indexscan_prefetch)
>>      {
>>          scan->xs_heapfetch->rs =
>>              read_stream_begin_relation(READ_STREAM_DEFAULT, NULL,
>>                                         scan->heapRelation, MAIN_FORKNUM,
>>   scan->heapRelation->rd_tableam->index_getnext_stream,
>>                                         scan, 0);
>>      }
>> #endif
>>
>> and ... see no difference.
>>
>> I can understand why initializing read stream earlier (not at the second
>> batch, but after 10 proceeded items) may have negative impact on
>> performance when all data is present i shared buffers for LIMIT>=10.
>> But how it can happen with LIMIT 1 and commented fragment above. There
>> is nothing else in my patch except adding GUC.
>> So I think that it is some "external" factor and wonder if you can
>> reproduce this results (just first line).
>>
> It seems this is due to sending an extra SET (for the new GUC) in the
> pgbench script, which is recognized only on the v5+threshold build.
>
> That's a thinko on my side, I should have realized the extra command
> might affect this. It doesn't really affect the behavior, because 10 is
> the default value for read_stream_threshold. I've fixed the script, will
> check fresh results tomorrow.
>
> Still, I think most of what I said about heuristics when to initialize
> the read stream, and the risk/benefit tradeoff, still applies.
>
>
> regards


Attached please find alternative version of the proposed patch which use 
number of disk reads as criteria for using read stream.


--------------ngqZY0dfHsEhC1M53tJJfux7
Content-Type: text/plain; charset=UTF-8; name="read_stream_threshold_v2.patch"
Content-Disposition: attachment; filename="read_stream_threshold_v2.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9oZWFwL2hlYXBhbV9oYW5kbGVyLmMg
Yi9zcmMvYmFja2VuZC9hY2Nlc3MvaGVhcC9oZWFwYW1faGFuZGxlci5jCmluZGV4IGI5ZDQy
YjE1YTE4Li4xMjViOGFkZGQ5YiAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvYWNjZXNzL2hl
YXAvaGVhcGFtX2hhbmRsZXIuYworKysgYi9zcmMvYmFja2VuZC9hY2Nlc3MvaGVhcC9oZWFw
YW1faGFuZGxlci5jCkBAIC0zNiw2ICszNiw3IEBACiAjaW5jbHVkZSAiY29tbWFuZHMvcHJv
Z3Jlc3MuaCIKICNpbmNsdWRlICJleGVjdXRvci9leGVjdXRvci5oIgogI2luY2x1ZGUgIm1p
c2NhZG1pbi5oIgorI2luY2x1ZGUgIm9wdGltaXplci9jb3N0LmgiCiAjaW5jbHVkZSAicGdz
dGF0LmgiCiAjaW5jbHVkZSAic3RvcmFnZS9idWZtZ3IuaCIKICNpbmNsdWRlICJzdG9yYWdl
L2J1ZnBhZ2UuaCIKQEAgLTQ2LDYgKzQ3LDggQEAKICNpbmNsdWRlICJ1dGlscy9idWlsdGlu
cy5oIgogI2luY2x1ZGUgInV0aWxzL3JlbC5oIgogCitpbnQgcmVhZF9zdHJlYW1fdGhyZXNo
b2xkID0gREVGQVVMVF9SRUFEX1NUUkVBTV9USFJFU0hPTEQ7CisKIHN0YXRpYyB2b2lkIHJl
Zm9ybV9hbmRfcmV3cml0ZV90dXBsZShIZWFwVHVwbGUgdHVwbGUsCiAJCQkJCQkJCQkgUmVs
YXRpb24gT2xkSGVhcCwgUmVsYXRpb24gTmV3SGVhcCwKIAkJCQkJCQkJCSBEYXR1bSAqdmFs
dWVzLCBib29sICppc251bGwsIFJld3JpdGVTdGF0ZSByd3N0YXRlKTsKQEAgLTg4LDYgKzkx
LDcgQEAgaGVhcGFtX2luZGV4X2ZldGNoX2JlZ2luKFJlbGF0aW9uIHJlbCkKIAogCWhzY2Fu
LT54c19iYXNlLnJlbCA9IHJlbDsKIAloc2Nhbi0+eHNfYmFzZS5ycyA9IE5VTEw7CisJaHNj
YW4tPnhzX2Jhc2Uubl9oZWFwX3JlYWRzID0gMDsKIAloc2Nhbi0+eHNfY2J1ZiA9IEludmFs
aWRCdWZmZXI7CiAJaHNjYW4tPnhzX2JsayA9IEludmFsaWRCbG9ja051bWJlcjsKIAloc2Nh
bi0+dm1idWYgPSBJbnZhbGlkQnVmZmVyOwpAQCAtMTYyLDcgKzE2NiwyMiBAQCBoZWFwYW1f
aW5kZXhfZmV0Y2hfdHVwbGUoc3RydWN0IEluZGV4RmV0Y2hUYWJsZURhdGEgKnNjYW4sCiAJ
CWlmIChzY2FuLT5ycykKIAkJCWhzY2FuLT54c19jYnVmID0gcmVhZF9zdHJlYW1fbmV4dF9i
dWZmZXIoc2Nhbi0+cnMsIE5VTEwpOwogCQllbHNlCi0JCQloc2Nhbi0+eHNfY2J1ZiA9IFJl
YWRCdWZmZXIoaHNjYW4tPnhzX2Jhc2UucmVsLCBoc2Nhbi0+eHNfYmxrKTsKKwkJeworCQkJ
UmVhZEJ1ZmZlcnNPcGVyYXRpb24gb3BlcmF0aW9uOworCQkJb3BlcmF0aW9uLnNtZ3IgPSBS
ZWxhdGlvbkdldFNtZ3IoaHNjYW4tPnhzX2Jhc2UucmVsKTsKKwkJCW9wZXJhdGlvbi5yZWwg
PSBoc2Nhbi0+eHNfYmFzZS5yZWw7CisJCQlvcGVyYXRpb24ucGVyc2lzdGVuY2UgPSBoc2Nh
bi0+eHNfYmFzZS5yZWwtPnJkX3JlbC0+cmVscGVyc2lzdGVuY2U7CisJCQlvcGVyYXRpb24u
Zm9ya251bSA9IE1BSU5fRk9SS05VTTsKKwkJCW9wZXJhdGlvbi5zdHJhdGVneSA9IE5VTEw7
CisJCQlpZiAoU3RhcnRSZWFkQnVmZmVyKCZvcGVyYXRpb24sCisJCQkJCQkJCSZoc2Nhbi0+
eHNfY2J1ZiwKKwkJCQkJCQkJaHNjYW4tPnhzX2JsaywKKwkJCQkJCQkJUkVBRF9CVUZGRVJT
X1NZTkNIUk9OT1VTTFkpKQorCQkJeworCQkJCVdhaXRSZWFkQnVmZmVycygmb3BlcmF0aW9u
KTsKKwkJCQlzY2FuLT5uX2hlYXBfcmVhZHMgKz0gMTsKKwkJCX0KKwkJfQogCiAJCS8qCiAJ
CSAqIFBydW5lIHBhZ2Ugd2hlbiBpdCBpcyBwaW5uZWQgZm9yIHRoZSBmaXJzdCB0aW1lCkBA
IC0yODgsNiArMzA3LDIwIEBAIGhlYXBfYmF0Y2hfYWR2YW5jZV9wb3MoSW5kZXhTY2FuRGVz
YyBzY2FuLCBzdHJ1Y3QgQmF0Y2hRdWV1ZUl0ZW1Qb3MgKnBvcywKIAkgKi8KIAliYXRjaCA9
IElOREVYX1NDQU5fQkFUQ0goc2NhbiwgcG9zLT5iYXRjaCk7CiAKKwkvKiBEZWxheSBpbml0
aWFsaXppbmcgc3RyZWFtIHVudGlsIHByb2NlZWRpbmcgKi8KKwlpZiAoIXNjYW4tPnhzX2hl
YXBmZXRjaC0+cnMKKwkJJiYgIXNjYW4tPmJhdGNocXVldWUtPmRpc2FibGVkCisJCSYmICFz
Y2FuLT54c193YW50X2l0dXAJLyogWFhYIHByZWZldGNoaW5nIGRpc2FibGVkIGZvciBJb1Ms
IGZvciBub3cgKi8KKwkJJiYgZW5hYmxlX2luZGV4c2Nhbl9wcmVmZXRjaAorCQkmJiBzY2Fu
LT54c19oZWFwZmV0Y2gtPm5faGVhcF9yZWFkcyA+PSAodWludDY0KXJlYWRfc3RyZWFtX3Ro
cmVzaG9sZCkgLyogLTEgLT4gK2luZiAqLworCXsKKwkJc2Nhbi0+eHNfaGVhcGZldGNoLT5y
cyA9CisJCQlyZWFkX3N0cmVhbV9iZWdpbl9yZWxhdGlvbihSRUFEX1NUUkVBTV9ERUZBVUxU
LCBOVUxMLAorCQkJCQkJCQkJICAgc2Nhbi0+aGVhcFJlbGF0aW9uLCBNQUlOX0ZPUktOVU0s
CisJCQkJCQkJCQkgICBzY2FuLT5oZWFwUmVsYXRpb24tPnJkX3RhYmxlYW0tPmluZGV4X2dl
dG5leHRfc3RyZWFtLAorCQkJCQkJCQkJICAgc2NhbiwgMCk7CisJfQorCiAJaWYgKFNjYW5E
aXJlY3Rpb25Jc0ZvcndhcmQoZGlyZWN0aW9uKSkKIAl7CiAJCWlmICgrK3Bvcy0+aXRlbSA8
PSBiYXRjaC0+bGFzdEl0ZW0pCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9hY2Nlc3MvaW5k
ZXgvaW5kZXhiYXRjaC5jIGIvc3JjL2JhY2tlbmQvYWNjZXNzL2luZGV4L2luZGV4YmF0Y2gu
YwppbmRleCAyOTIwNzI3NmRjYS4uZDJmYTU1MTkzNzggMTAwNjQ0Ci0tLSBhL3NyYy9iYWNr
ZW5kL2FjY2Vzcy9pbmRleC9pbmRleGJhdGNoLmMKKysrIGIvc3JjL2JhY2tlbmQvYWNjZXNz
L2luZGV4L2luZGV4YmF0Y2guYwpAQCAtMTY5LDE3ICsxNjksNiBAQCBiYXRjaF9nZXRuZXh0
KEluZGV4U2NhbkRlc2Mgc2NhbiwgU2NhbkRpcmVjdGlvbiBkaXJlY3Rpb24pCiAKIAkJREVC
VUdfTE9HKCJiYXRjaF9nZXRuZXh0IGhlYWRCYXRjaCAlZCBuZXh0QmF0Y2ggJWQgYmF0Y2gg
JXAiLAogCQkJCSAgYmF0Y2hxdWV1ZS0+aGVhZEJhdGNoLCBiYXRjaHF1ZXVlLT5uZXh0QmF0
Y2gsIGJhdGNoKTsKLQotCQkvKiBEZWxheSBpbml0aWFsaXppbmcgc3RyZWFtIHVudGlsIHJl
YWRpbmcgZnJvbSBzY2FuJ3Mgc2Vjb25kIGJhdGNoICovCi0JCWlmIChwcmlvcmJhdGNoICYm
ICFzY2FuLT54c19oZWFwZmV0Y2gtPnJzICYmICFiYXRjaHF1ZXVlLT5kaXNhYmxlZCAmJgot
CQkJIXNjYW4tPnhzX3dhbnRfaXR1cCAmJgkvKiBYWFggcHJlZmV0Y2hpbmcgZGlzYWJsZWQg
Zm9yIElvUywgZm9yCi0JCQkJCQkJCQkgKiBub3cgKi8KLQkJCWVuYWJsZV9pbmRleHNjYW5f
cHJlZmV0Y2gpCi0JCQlzY2FuLT54c19oZWFwZmV0Y2gtPnJzID0KLQkJCQlyZWFkX3N0cmVh
bV9iZWdpbl9yZWxhdGlvbihSRUFEX1NUUkVBTV9ERUZBVUxULCBOVUxMLAotCQkJCQkJCQkJ
CSAgIHNjYW4tPmhlYXBSZWxhdGlvbiwgTUFJTl9GT1JLTlVNLAotCQkJCQkJCQkJCSAgIHNj
YW4tPmhlYXBSZWxhdGlvbi0+cmRfdGFibGVhbS0+aW5kZXhfZ2V0bmV4dF9zdHJlYW0sCi0J
CQkJCQkJCQkJICAgc2NhbiwgMCk7CiAJfQogCWVsc2UKIAkJc2Nhbi0+ZmluaXNoZWQgPSB0
cnVlOwpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvdXRpbHMvbWlzYy9ndWNfcGFyYW1ldGVy
cy5kYXQgYi9zcmMvYmFja2VuZC91dGlscy9taXNjL2d1Y19wYXJhbWV0ZXJzLmRhdAppbmRl
eCA4ZjZmYTY4NDNjYi4uMGMwODE5ZTRkMTMgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3V0
aWxzL21pc2MvZ3VjX3BhcmFtZXRlcnMuZGF0CisrKyBiL3NyYy9iYWNrZW5kL3V0aWxzL21p
c2MvZ3VjX3BhcmFtZXRlcnMuZGF0CkBAIC0yMzIyLDYgKzIzMjIsMTYgQEAKICAgbWF4ID0+
ICdEQkxfTUFYJywKIH0sCiAKK3sgbmFtZSA9PiAncmVhZF9zdHJlYW1fdGhyZXNob2xkJywg
dHlwZSA9PiAnaW50JywgY29udGV4dCA9PiAnUEdDX1VTRVJTRVQnLCBncm91cCA9PiAnUVVF
UllfVFVOSU5HX0NPU1QnLAorICBzaG9ydF9kZXNjID0+ICdNaW5pbWFsIG51bWJlciBvZiBo
ZWFwIHJlYWRzIGR1cmluZyBpbmRleCBzY2FuIGZvciBjcmVhdGlvbiBvZiByZWFkIHN0cmVh
bScsCisgIGxvbmdfZGVzYyA9PiAnSW5kZXggc2NhbiBuZWVkcyB0byByZWFkIGhlYXAgdG8g
Y2hlY2sgdmlzaWJpbGl0eSBvZiB0dXBsZXMgYW5kIGdldCBhdHRyaWJ1dGVzIG5vdCBwcmVz
ZW50IGluIGluZGV4IGtleS4gUmVhZCBzdHJlYW0gYWxsb3dzIHRvIGRvIGl0IGFzeW5jaHJv
bm91c2x5IHdoaWNoIGFkZHMgZXh0cmEgb3ZlcmhlYWQsIGJ1dCBhbGxvd3MgdG8gc2lnbmlm
aWNhbnRseSBpbmNyZWFzZSBzcGVlZCBmb3IgbG9uZyBzY2Fucy4gU3BlY2lmeSAtMSB0byBk
aXNhYmxlLicsCisgIGZsYWdzID0+ICdHVUNfRVhQTEFJTicsCisgIHZhcmlhYmxlID0+ICdy
ZWFkX3N0cmVhbV90aHJlc2hvbGQnLAorICBib290X3ZhbCA9PiAnREVGQVVMVF9SRUFEX1NU
UkVBTV9USFJFU0hPTEQnLAorICBtaW4gPT4gJy0xJywKKyAgbWF4ID0+ICdJTlRfTUFYJywK
K30sCisKIHsgbmFtZSA9PiAncmVjb3ZlcnlfZW5kX2NvbW1hbmQnLCB0eXBlID0+ICdzdHJp
bmcnLCBjb250ZXh0ID0+ICdQR0NfU0lHSFVQJywgZ3JvdXAgPT4gJ1dBTF9BUkNISVZFX1JF
Q09WRVJZJywKICAgc2hvcnRfZGVzYyA9PiAnU2V0cyB0aGUgc2hlbGwgY29tbWFuZCB0aGF0
IHdpbGwgYmUgZXhlY3V0ZWQgb25jZSBhdCB0aGUgZW5kIG9mIHJlY292ZXJ5LicsCiAgIHZh
cmlhYmxlID0+ICdyZWNvdmVyeUVuZENvbW1hbmQnLApkaWZmIC0tZ2l0IGEvc3JjL2luY2x1
ZGUvYWNjZXNzL3JlbHNjYW4uaCBiL3NyYy9pbmNsdWRlL2FjY2Vzcy9yZWxzY2FuLmgKaW5k
ZXggMTE1N2JhOWJhOWQuLjk2OTBkODlhZDhhIDEwMDY0NAotLS0gYS9zcmMvaW5jbHVkZS9h
Y2Nlc3MvcmVsc2Nhbi5oCisrKyBiL3NyYy9pbmNsdWRlL2FjY2Vzcy9yZWxzY2FuLmgKQEAg
LTEyNiw2ICsxMjYsNyBAQCB0eXBlZGVmIHN0cnVjdCBJbmRleEZldGNoVGFibGVEYXRhCiB7
CiAJUmVsYXRpb24JcmVsOwogCVJlYWRTdHJlYW0gKnJzOworCXVpbnQ2NAkJbl9oZWFwX3Jl
YWRzOyAgIC8qIG51bWJlciBvZiBoZWFwIHBhZ2UgcmVhZCBmcm9tIHRoZSBkaXNrICovCiB9
IEluZGV4RmV0Y2hUYWJsZURhdGE7CiAKIC8qCmRpZmYgLS1naXQgYS9zcmMvaW5jbHVkZS9v
cHRpbWl6ZXIvY29zdC5oIGIvc3JjL2luY2x1ZGUvb3B0aW1pemVyL2Nvc3QuaAppbmRleCAw
MGY0YzNkMDAxMS4uOTcxNTA0MzNjOTkgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRlL29wdGlt
aXplci9jb3N0LmgKKysrIGIvc3JjL2luY2x1ZGUvb3B0aW1pemVyL2Nvc3QuaApAQCAtMjgs
NiArMjgsNyBAQAogI2RlZmluZSBERUZBVUxUX0NQVV9PUEVSQVRPUl9DT1NUICAwLjAwMjUK
ICNkZWZpbmUgREVGQVVMVF9QQVJBTExFTF9UVVBMRV9DT1NUIDAuMQogI2RlZmluZSBERUZB
VUxUX1BBUkFMTEVMX1NFVFVQX0NPU1QgIDEwMDAuMAorI2RlZmluZSBERUZBVUxUX1JFQURf
U1RSRUFNX1RIUkVTSE9MRAkxMAogCiAvKiBkZWZhdWx0cyBmb3Igbm9uLUNvc3QgcGFyYW1l
dGVycyAqLwogI2RlZmluZSBERUZBVUxUX1JFQ1VSU0lWRV9XT1JLVEFCTEVfRkFDVE9SICAx
MC4wCkBAIC03Miw2ICs3Myw3IEBAIGV4dGVybiBQR0RMTElNUE9SVCBib29sIGVuYWJsZV9w
YXJ0aXRpb25fcHJ1bmluZzsKIGV4dGVybiBQR0RMTElNUE9SVCBib29sIGVuYWJsZV9wcmVz
b3J0ZWRfYWdncmVnYXRlOwogZXh0ZXJuIFBHRExMSU1QT1JUIGJvb2wgZW5hYmxlX2FzeW5j
X2FwcGVuZDsKIGV4dGVybiBQR0RMTElNUE9SVCBpbnQgY29uc3RyYWludF9leGNsdXNpb247
CitleHRlcm4gUEdETExJTVBPUlQgaW50IHJlYWRfc3RyZWFtX3RocmVzaG9sZDsKIAogZXh0
ZXJuIGRvdWJsZSBpbmRleF9wYWdlc19mZXRjaGVkKGRvdWJsZSB0dXBsZXNfZmV0Y2hlZCwg
QmxvY2tOdW1iZXIgcGFnZXMsCiAJCQkJCQkJCSAgZG91YmxlIGluZGV4X3BhZ2VzLCBQbGFu
bmVySW5mbyAqcm9vdCk7Cg==

--------------ngqZY0dfHsEhC1M53tJJfux7--