MIME-Version: 1.0
References: 
 <CA+3i_M-+WVyrRcfnxa4gt+KQUzH-LTQ8D2JCGE_O0WzJJtZfUg@mail.gmail.com>
 <CAHg+QDfLh-yb+OacN6qPYF6H3SPDmVJUiors7vkSMq4yxfhNrA@mail.gmail.com>
 <CALj2ACWovfe_A43LP5fi0mJenZ-i99_ux68YCzX6D2CO5mB-gg@mail.gmail.com>
 <CAKZiRmwuKVHaQa_3PirbBqzoCKciuqcn2Tn4Df4d8icq4e3DCA@mail.gmail.com>
 <CA+3i_M9s6T-jOsvSZk5y1HVvyz_RVbiEQZGdwPRQrw+zZcZ5Eg@mail.gmail.com>
 <CAKZiRmz3n24HZVzQX4=25y4tMZ9PjYQjmbGhJkrziAQjdHru5g@mail.gmail.com>
In-Reply-To: 
 <CAKZiRmz3n24HZVzQX4=25y4tMZ9PjYQjmbGhJkrziAQjdHru5g@mail.gmail.com>
From: Lakshmi N <lakshmin.jhs@gmail.com>
Date: Tue, 24 Mar 2026 05:07:40 -0700
Message-ID: 
 <CA+3i_M8C+rK9vhwBm8U+ys2hbDifoBb4Xnws5Wmn2f4u7iqOpA@mail.gmail.com>
Subject: Re: log XLogPrefetch stats at end of recovery
To: Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
 pgsql-hackers@postgresql.org
Content-Type: multipart/mixed; boundary="00000000000027407f064dc4008e"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2B3i_M8C%2BrK9vhwBm8U%2Bys2hbDifoBb4Xnws5Wmn2f4u7iqOpA%40mail.gmail.com>
Precedence: bulk

--00000000000027407f064dc4008e
Content-Type: multipart/alternative; boundary="00000000000027407e064dc4008c"

--00000000000027407e064dc4008c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Mar 24, 2026 at 1:53=E2=80=AFAM Jakub Wartak <jakub.wartak@enterpri=
sedb.com>
wrote:

> On Tue, Mar 24, 2026 at 9:28=E2=80=AFAM Lakshmi N <lakshmin.jhs@gmail.com=
> wrote:
> >
> > Hi all,
> >
> > Thank you for your feedback. Please see the attached patch.
> >
> > On Mon, Mar 23, 2026 at 4:30=E2=80=AFAM Jakub Wartak <
> jakub.wartak@enterprisedb.com> wrote:
> >>
> >> On Sun, Mar 22, 2026 at 1:43=E2=80=AFAM Bharath Rupireddy
> >> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> > On Sat, Mar 21, 2026 at 1:16=E2=80=AFAM SATYANARAYANA NARLAPURAM
> >> > <satyanarlapuram@gmail.com> wrote:
> >> > >
> >> > > > While investigating a long recovery, I noticed that XLogPrefetch
> stats were not logged at the end of recovery. This log message will be
> useful to understand how effective XLogPrefetch was during recovery. Addi=
ng
> a patch to address this.
> >> > >
> >> > > Applied this patch and validated the log message. This log message
> appears to be useful to me, particularly while doing fleet wide analysis.
> >> > >
> >> > > 2026-03-20 23:33:13.756 PDT [2265441] LOG:  XLogPrefetcher stats:
> prefetch=3D14, hit=3D6, skip_init=3D5, skip_new=3D28, skip_fpw=3D18, skip=
_rep=3D996
> >> >
> >> > This looks useful to understand how the prefetch helped during long
> recoveries.
> >> >
> >> > > I am wondering if we can periodically log this in standby mode as
> well, not just before promoting?
> >> >
> >> > Timer-based startup progress messaging allows logging such things
> >> > (ereport_startup_progress API). There was an attempt to enable "redo
> >> > in progress" for standbys, but that seemed to flood the standby logs
> >> > even at the default progress interval of 10 sec.
> >> >
> >> > Having said that, the prefetcher stats could be added to the existin=
g
> >> > ereport_startup_progress("redo in progress xxx") message that works
> >> > for crash recoveries=E2=80=94however, I don't prefer doing a bunch o=
f atomic
> >> > reads every progress interval of 10 sec.
> >>
> >> > Therefore, logging at the end of recovery looks good to me.
> >>
> >> +1 from me too to only of logging at the end of recovery (so -1 to
> logging
> >> every now and then). If someone is interested in current state (or
> progress
> >> over time) I think he can query pg_stat_recovery_prefetch view already=
,
> even
> >> today, right?
> >>
> >> > I reviewed the patch. I have the following comment:
> >> >
> >> > + elog(LOG, "XLogPrefetcher stats: prefetch=3D%lu, hit=3D%lu,
> >> > skip_init=3D%lu, skip_new=3D%lu, skip_fpw=3D%lu, skip_rep=3D%lu",
> >> >
> >> > XLogPrefetcher is an internal data structure name, how about "redo
> >> > prefetch stats: xxxx" to be consistent with other redo log messages?
> >>
> >> +1
> >
> >
> > please find the attached patch addressing this.
>
> Hi Lakshmi,
>
> The pg_stat_get_recovery_prefetch view has 3 additional columns, but they
> are
> showing current situation, maybe this $patch could be enhanced so that it
> also
> calculates averages for some of them? I mean perhaps not just hit ratio
> would be
> nice, but also the e.g. __average__ wal distance or average look ahead
> (block distance).
> I'm not sure maybe please also wait for input from others if they find
> it a good idea
> or not.
>
> Also if we are adding such pretty cryptic fields as "skip_fpw" to log,
> we would need some
> place in documentaiton to explain their meaining probably.
> monitoring.sgml already
> explains them, so maybe just link to that. I mean if you look what we
> have today (below),
> they are little less crypting and have different format, not
> "skip_fpw=3D123" but more
> like "17 removed" so maybe "17 skipped due to FPW". Maybe
>
> redo done at 0/75C7B290 system usage: CPU: user: 1.02 s, system: 0.51
> s, elapsed: 1.53 s
> checkpoint complete: end-of-recovery fast wait: wrote 16289 buffers
> (99.4%), wrote 3 SLRU buffers; 0 WAL file(s) added, 17 removed, 0
> recycled; write=3D0.049 s, sync=3D0.191 s, total=3D0.264 s; sync files=3D=
10,
> longest=3D0.187 s, average=3D0.020 s; distance=3D287186 kB, estimate=3D28=
7186
> kB; lsn=3D0/75C7B2C8, redo lsn=3D0/75C7B2C8
>
> so instead of like:
> redo prefetch stats: prefetch=3D%lu, hit=3D%lu, skip_init=3D%lu,
> skip_new=3D%lu, skip_fpw=3D%lu, skip_rep=3D%lu"
>
> something like below ones:
> redo prefetch stats: done %lu prefetches, %lu hit, %lu zero-initated, ..
> redo prefetch stats: done %lu prefetches, (%d% hit ratio), %lu
> zero-initated, .. or something like that
>

Please find the attached patch with the suggested changes. I referenced [1]
to log the message as suggested.

2026-03-24 04:53:15.251 PDT [18898] LOG:  redo prefetch stats: prefetched
27 blocks, skipped 22 blocks because they were already in the buffer pool,
skipped 17 blocks because they would be zero-initialized, skipped 0 blocks
because they didn't exist yet, skipped 28 blocks because a full page image
was included in the WAL, skipped 155 blocks because they were already
recently prefetched.

[1]
https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-S=
TAT-RECOVERY-PREFETCH

Regards,
Lakshmi

--00000000000027407e064dc4008c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 24, =
2026 at 1:53=E2=80=AFAM Jakub Wartak &lt;<a href=3D"mailto:jakub.wartak@ent=
erprisedb.com">jakub.wartak@enterprisedb.com</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 24, 2026 at 9:28=E2=
=80=AFAM Lakshmi N &lt;<a href=3D"mailto:lakshmin.jhs@gmail.com" target=3D"=
_blank">lakshmin.jhs@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; Thank you for your feedback. Please see the attached patch.<br>
&gt;<br>
&gt; On Mon, Mar 23, 2026 at 4:30=E2=80=AFAM Jakub Wartak &lt;<a href=3D"ma=
ilto:jakub.wartak@enterprisedb.com" target=3D"_blank">jakub.wartak@enterpri=
sedb.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Mar 22, 2026 at 1:43=E2=80=AFAM Bharath Rupireddy<br>
&gt;&gt; &lt;<a href=3D"mailto:bharath.rupireddyforpostgres@gmail.com" targ=
et=3D"_blank">bharath.rupireddyforpostgres@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; &gt; On Sat, Mar 21, 2026 at 1:16=E2=80=AFAM SATYANARAYANA NARLAPU=
RAM<br>
&gt;&gt; &gt; &lt;<a href=3D"mailto:satyanarlapuram@gmail.com" target=3D"_b=
lank">satyanarlapuram@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &gt; While investigating a long recovery, I noticed that=
 XLogPrefetch stats were not logged at the end of recovery. This log messag=
e will be useful to understand how effective XLogPrefetch was during recove=
ry. Adding a patch to address this.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Applied this patch and validated the log message. This l=
og message appears to be useful to me, particularly while doing fleet wide =
analysis.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; 2026-03-20 23:33:13.756 PDT [2265441] LOG:=C2=A0 XLogPre=
fetcher stats: prefetch=3D14, hit=3D6, skip_init=3D5, skip_new=3D28, skip_f=
pw=3D18, skip_rep=3D996<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; This looks useful to understand how the prefetch helped durin=
g long recoveries.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; I am wondering if we can periodically log this in standb=
y mode as well, not just before promoting?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Timer-based startup progress messaging allows logging such th=
ings<br>
&gt;&gt; &gt; (ereport_startup_progress API). There was an attempt to enabl=
e &quot;redo<br>
&gt;&gt; &gt; in progress&quot; for standbys, but that seemed to flood the =
standby logs<br>
&gt;&gt; &gt; even at the default progress interval of 10 sec.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Having said that, the prefetcher stats could be added to the =
existing<br>
&gt;&gt; &gt; ereport_startup_progress(&quot;redo in progress xxx&quot;) me=
ssage that works<br>
&gt;&gt; &gt; for crash recoveries=E2=80=94however, I don&#39;t prefer doin=
g a bunch of atomic<br>
&gt;&gt; &gt; reads every progress interval of 10 sec.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Therefore, logging at the end of recovery looks good to me.<b=
r>
&gt;&gt;<br>
&gt;&gt; +1 from me too to only of logging at the end of recovery (so -1 to=
 logging<br>
&gt;&gt; every now and then). If someone is interested in current state (or=
 progress<br>
&gt;&gt; over time) I think he can query pg_stat_recovery_prefetch view alr=
eady, even<br>
&gt;&gt; today, right?<br>
&gt;&gt;<br>
&gt;&gt; &gt; I reviewed the patch. I have the following comment:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; + elog(LOG, &quot;XLogPrefetcher stats: prefetch=3D%lu, hit=
=3D%lu,<br>
&gt;&gt; &gt; skip_init=3D%lu, skip_new=3D%lu, skip_fpw=3D%lu, skip_rep=3D%=
lu&quot;,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; XLogPrefetcher is an internal data structure name, how about =
&quot;redo<br>
&gt;&gt; &gt; prefetch stats: xxxx&quot; to be consistent with other redo l=
og messages?<br>
&gt;&gt;<br>
&gt;&gt; +1<br>
&gt;<br>
&gt;<br>
&gt; please find the attached patch addressing this.<br>
<br>
Hi Lakshmi,<br>
<br>
The pg_stat_get_recovery_prefetch view has 3 additional columns, but they a=
re<br>
showing current situation, maybe this $patch could be enhanced so that it a=
lso<br>
calculates averages for some of them? I mean perhaps not just hit ratio wou=
ld be<br>
nice, but also the e.g. __average__ wal distance or average look ahead<br>
(block distance).<br>
I&#39;m not sure maybe please also wait for input from others if they find<=
br>
it a good idea<br>
or not.<br>
<br>
Also if we are adding such pretty cryptic fields as &quot;skip_fpw&quot; to=
 log,<br>
we would need some<br>
place in documentaiton to explain their meaining probably.<br>
monitoring.sgml already<br>
explains them, so maybe just link to that. I mean if you look what we<br>
have today (below),<br>
they are little less crypting and have different format, not<br>
&quot;skip_fpw=3D123&quot; but more<br>
like &quot;17 removed&quot; so maybe &quot;17 skipped due to FPW&quot;. May=
be<br>
<br>
redo done at 0/75C7B290 system usage: CPU: user: 1.02 s, system: 0.51<br>
s, elapsed: 1.53 s<br>
checkpoint complete: end-of-recovery fast wait: wrote 16289 buffers<br>
(99.4%), wrote 3 SLRU buffers; 0 WAL file(s) added, 17 removed, 0<br>
recycled; write=3D0.049 s, sync=3D0.191 s, total=3D0.264 s; sync files=3D10=
,<br>
longest=3D0.187 s, average=3D0.020 s; distance=3D287186 kB, estimate=3D2871=
86<br>
kB; lsn=3D0/75C7B2C8, redo lsn=3D0/75C7B2C8<br>
<br>
so instead of like:<br>
redo prefetch stats: prefetch=3D%lu, hit=3D%lu, skip_init=3D%lu,<br>
skip_new=3D%lu, skip_fpw=3D%lu, skip_rep=3D%lu&quot;<br>
<br>
something like below ones:<br>
redo prefetch stats: done %lu prefetches, %lu hit, %lu zero-initated, ..<br=
>
redo prefetch stats: done %lu prefetches, (%d% hit ratio), %lu<br>
zero-initated, .. or something like that<br></blockquote><div><br></div><di=
v>Please find the attached patch with the suggested changes. I referenced [=
1] to log the message as suggested.</div><div><br></div><div>2026-03-24 04:=
53:15.251 PDT [18898] LOG: =C2=A0redo prefetch stats: prefetched 27 blocks,=
 skipped 22 blocks because they were already in the buffer pool, skipped 17=
 blocks because they would be zero-initialized, skipped 0 blocks because th=
ey didn&#39;t exist yet, skipped 28 blocks because a full page image was in=
cluded in the WAL, skipped 155 blocks because they were already recently pr=
efetched.=C2=A0</div><div><br></div><div>[1] <a href=3D"https://www.postgre=
sql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-RECOVERY-PREFET=
CH">https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-=
PG-STAT-RECOVERY-PREFETCH</a></div><div><br></div><div>Regards,</div><div>L=
akshmi=C2=A0</div></div></div>

--00000000000027407e064dc4008c--

--00000000000027407f064dc4008e
Content-Type: application/octet-stream;
	name="0001-log-prefetch-stats-at-end-of-recovery.patch"
Content-Disposition: attachment;
	filename="0001-log-prefetch-stats-at-end-of-recovery.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mn4kkdn80>
X-Attachment-Id: f_mn4kkdn80

RnJvbSA2YzI5YWM2YWMyOTcwMTRmY2ViMmUwMmJkMTVjNTNlZTQ2M2FjMjgxIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMYWtzaG1pIE4gPGxha3NobWluLmpoc0BnbWFpbC5jb20+CkRh
dGU6IFR1ZSwgMjQgTWFyIDIwMjYgMDE6MjM6MjQgLTA3MDAKU3ViamVjdDogW1BBVENIXSB4bG9n
cHJlZmV0Y2hlcjogbG9nIHByZWZldGNoIHN0YXRpc3RpY3MgYXQgZW5kIG9mIHJlY292ZXJ5CgpB
ZGQgWExvZ1ByZWZldGNoTG9nU3RhdHMoKSwgd2hpY2ggZW1pdHMgYSBMT0cgbWVzc2FnZSBzdW1t
YXJpc2luZyB0aGUKcHJlZmV0Y2ggY291bnRlcnMgKHByZWZldGNoLCBoaXQsIHNraXBfaW5pdCwg
c2tpcF9uZXcsIHNraXBfZnB3LApza2lwX3JlcCkgYWNjdW11bGF0ZWQgZHVyaW5nIHJlY292ZXJ5
LiBUaGUgZnVuY3Rpb24gaXMgY2FsbGVkIGZyb20KUGVyZm9ybVdhbFJlY292ZXJ5KCkgaW1tZWRp
YXRlbHkgYWZ0ZXIgdGhlICJyZWRvIGRvbmUiIG1lc3NhZ2UsIGdpdmluZwpvcGVyYXRvcnMgdmlz
aWJpbGl0eSBpbnRvIGhvdyBlZmZlY3RpdmUgV0FMIHByZWZldGNoaW5nIHdhcyBvdmVyIHRoZQpj
b3Vyc2Ugb2YgdGhlIHJlY292ZXJ5IHNlc3Npb24uCgpOby1vcCB3aGVuIHJlY292ZXJ5X3ByZWZl
dGNoID0gb2ZmLgotLS0KIHNyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL3hsb2dwcmVmZXRjaGVy
LmMgfCAyNSArKysrKysrKysrKysrKysrKysrKysKIHNyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2Ft
L3hsb2dyZWNvdmVyeS5jICAgfCAgMiArKwogc3JjL2luY2x1ZGUvYWNjZXNzL3hsb2dwcmVmZXRj
aGVyLmggICAgICAgICB8ICAyICsrCiAzIGZpbGVzIGNoYW5nZWQsIDI5IGluc2VydGlvbnMoKykK
CmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9hY2Nlc3MvdHJhbnNhbS94bG9ncHJlZmV0Y2hlci5j
IGIvc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0veGxvZ3ByZWZldGNoZXIuYwppbmRleCBjMjM1
ZWNhN2M1MS4uNzZiZTBjYzFiY2YgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL2FjY2Vzcy90cmFu
c2FtL3hsb2dwcmVmZXRjaGVyLmMKKysrIGIvc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0veGxv
Z3ByZWZldGNoZXIuYwpAQCAtMzM1LDYgKzMzNSwzMSBAQCBYTG9nUHJlZmV0Y2hTaG1lbUluaXQo
dm9pZCkKIAl9CiB9CiAKKy8qCisgKiBMb2cgYSBzdW1tYXJ5IG9mIHRoZSBYTG9nUHJlZmV0Y2hl
ciBzdGF0cy4gSW50ZW5kZWQgdG8gYmUgY2FsbGVkCisgKiBhdCB0aGUgZW5kIG9mIHJlY292ZXJ5
IG9yIHdoZW4gYSBzdGFuZGJ5IGlzIHByb21vdGVkLgorICovCit2b2lkCitYTG9nUHJlZmV0Y2hM
b2dTdGF0cyh2b2lkKQoreworCWlmIChyZWNvdmVyeV9wcmVmZXRjaCA9PSBSRUNPVkVSWV9QUkVG
RVRDSF9PRkYpCisJCXJldHVybjsKKworCWVsb2coTE9HLAorCQkicmVkbyBwcmVmZXRjaCBzdGF0
czogcHJlZmV0Y2hlZCAlbHUgYmxvY2tzLCAiCisJCSJza2lwcGVkICVsdSBibG9ja3MgYmVjYXVz
ZSB0aGV5IHdlcmUgYWxyZWFkeSBpbiB0aGUgYnVmZmVyIHBvb2wsICIKKwkJInNraXBwZWQgJWx1
IGJsb2NrcyBiZWNhdXNlIHRoZXkgd291bGQgYmUgemVyby1pbml0aWFsaXplZCwgIgorCQkic2tp
cHBlZCAlbHUgYmxvY2tzIGJlY2F1c2UgdGhleSBkaWRuJ3QgZXhpc3QgeWV0LCAiCisJCSJza2lw
cGVkICVsdSBibG9ja3MgYmVjYXVzZSBhIGZ1bGwgcGFnZSBpbWFnZSB3YXMgaW5jbHVkZWQgaW4g
dGhlIFdBTCwgIgorCQkic2tpcHBlZCAlbHUgYmxvY2tzIGJlY2F1c2UgdGhleSB3ZXJlIGFscmVh
ZHkgcmVjZW50bHkgcHJlZmV0Y2hlZC4iLAorCQlwZ19hdG9taWNfcmVhZF91NjQoJlNoYXJlZFN0
YXRzLT5wcmVmZXRjaCksCisJCXBnX2F0b21pY19yZWFkX3U2NCgmU2hhcmVkU3RhdHMtPmhpdCks
CisJCXBnX2F0b21pY19yZWFkX3U2NCgmU2hhcmVkU3RhdHMtPnNraXBfaW5pdCksCisJCXBnX2F0
b21pY19yZWFkX3U2NCgmU2hhcmVkU3RhdHMtPnNraXBfbmV3KSwKKwkJcGdfYXRvbWljX3JlYWRf
dTY0KCZTaGFyZWRTdGF0cy0+c2tpcF9mcHcpLAorCQlwZ19hdG9taWNfcmVhZF91NjQoJlNoYXJl
ZFN0YXRzLT5za2lwX3JlcCkpOworfQorCiAvKgogICogQ2FsbGVkIHdoZW4gYW55IEdVQyBpcyBj
aGFuZ2VkIHRoYXQgYWZmZWN0cyBwcmVmZXRjaGluZy4KICAqLwpkaWZmIC0tZ2l0IGEvc3JjL2Jh
Y2tlbmQvYWNjZXNzL3RyYW5zYW0veGxvZ3JlY292ZXJ5LmMgYi9zcmMvYmFja2VuZC9hY2Nlc3Mv
dHJhbnNhbS94bG9ncmVjb3ZlcnkuYwppbmRleCA2ZDJjNGE4NmI5Ni4uNzQyY2I5MGRhOWIgMTAw
NjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL3hsb2dyZWNvdmVyeS5jCisrKyBi
L3NyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL3hsb2dyZWNvdmVyeS5jCkBAIC0xODQ1LDYgKzE4
NDUsOCBAQCBQZXJmb3JtV2FsUmVjb3Zlcnkodm9pZCkKIAkJCQllcnJtc2coInJlZG8gZG9uZSBh
dCAlWC8lMDhYIHN5c3RlbSB1c2FnZTogJXMiLAogCQkJCQkgICBMU05fRk9STUFUX0FSR1MoeGxv
Z3JlYWRlci0+UmVhZFJlY1B0ciksCiAJCQkJCSAgIHBnX3J1c2FnZV9zaG93KCZydTApKSk7CisJ
CQorCQlYTG9nUHJlZmV0Y2hMb2dTdGF0cygpOwogCQl4dGltZSA9IEdldExhdGVzdFhUaW1lKCk7
CiAJCWlmICh4dGltZSkKIAkJCWVyZXBvcnQoTE9HLApkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUv
YWNjZXNzL3hsb2dwcmVmZXRjaGVyLmggYi9zcmMvaW5jbHVkZS9hY2Nlc3MveGxvZ3ByZWZldGNo
ZXIuaAppbmRleCA3ZWM0MGM0Yjc4Yi4uYTg2MjkyNGM4OTUgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNs
dWRlL2FjY2Vzcy94bG9ncHJlZmV0Y2hlci5oCisrKyBiL3NyYy9pbmNsdWRlL2FjY2Vzcy94bG9n
cHJlZmV0Y2hlci5oCkBAIC0zNyw2ICszNyw3IEBAIGV4dGVybiB2b2lkIFhMb2dQcmVmZXRjaFJl
Y29uZmlndXJlKHZvaWQpOwogZXh0ZXJuIHNpemVfdCBYTG9nUHJlZmV0Y2hTaG1lbVNpemUodm9p
ZCk7CiBleHRlcm4gdm9pZCBYTG9nUHJlZmV0Y2hTaG1lbUluaXQodm9pZCk7CgorZXh0ZXJuIHZv
aWQgWExvZ1ByZWZldGNoTG9nU3RhdHModm9pZCk7CiBleHRlcm4gdm9pZCBYTG9nUHJlZmV0Y2hS
ZXNldFN0YXRzKHZvaWQpOwogCiBleHRlcm4gWExvZ1ByZWZldGNoZXIgKlhMb2dQcmVmZXRjaGVy
QWxsb2NhdGUoWExvZ1JlYWRlclN0YXRlICpyZWFkZXIpOwpAQCAtNTIsNCArNTMsNSBAQCBleHRl
cm4gWExvZ1JlY29yZCAqWExvZ1ByZWZldGNoZXJSZWFkUmVjb3JkKFhMb2dQcmVmZXRjaGVyICpw
cmVmZXRjaGVyLAogCiBleHRlcm4gdm9pZCBYTG9nUHJlZmV0Y2hlckNvbXB1dGVTdGF0cyhYTG9n
UHJlZmV0Y2hlciAqcHJlZmV0Y2hlcik7CiAKKwogI2VuZGlmCi0tIAoyLjQzLjAKCg==
--00000000000027407f064dc4008e--