MIME-Version: 1.0
References: <19490-9c59c6a583513b99@postgresql.org>
 <46FE61C9-F273-45FD-BED7-0F8CDA6EB992@yandex-team.ru>
 <CAL9smLBMxKBCmsA9UGcmf93bT2_MsZ+POH-oHREuwKdmMU7jfQ@mail.gmail.com>
 <46DB3CAB-EA1C-41A5-9D6D-5F913A2AAF66@yandex-team.ru>
 <CAJgoLkJfFgL-V+pYB7=R81AbURTE6sMhzVHDQDhVGnfXRSJ9Wg@mail.gmail.com>
 <CAJgoLkKCu0wCwPQZSo5no=XATU-4LMK4QfKBwV928o2uKcxe=g@mail.gmail.com>
In-Reply-To: 
 <CAJgoLkKCu0wCwPQZSo5no=XATU-4LMK4QfKBwV928o2uKcxe=g@mail.gmail.com>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Fri, 22 May 2026 22:21:32 +0530
Message-ID: 
 <CAJTYsWU6tdEvVh4YKLxz7+amZ7+Wb7_s-FBjsMMeLNj1fKeSNg@mail.gmail.com>
Subject: Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on
 MultiXactOffsetSLRU when primary is 16.8
To: Radim Marek <radim@boringsql.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
	Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Marko Tiikkaja <marko@joh.to>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="0000000000000646a506526ad898"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWU6tdEvVh4YKLxz7%2BamZ7%2BWb7_s-FBjsMMeLNj1fKeSNg%40mail.gmail.com>
Precedence: bulk

--0000000000000646a506526ad898
Content-Type: multipart/alternative; boundary="0000000000000646a406526ad896"

--0000000000000646a406526ad896
Content-Type: text/plain; charset="UTF-8"

Hi,

On Thu, 21 May 2026 at 14:36, Radim Marek <radim@boringsql.com> wrote:

> Altough the culprit is known, I've got more data as requested.
>
> #0  0x00007f20e9bdb687 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007f20e9bdbc8c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00007f20e9be6920 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x000055a71796e3ca in PGSemaphoreLock (sema=0x7f20de6d0e38) at
> ./build/src/backend/port/pg_sema.c:327
> #4  0x000055a7179f57ed in LWLockAcquire (lock=0x7f20de6d1800,
> mode=mode@entry=LW_EXCLUSIVE) at
> ./build/../src/backend/storage/lmgr/lwlock.c:1314
> #5  0x000055a71772dfb2 in SimpleLruWriteAll (ctl=ctl@entry=0x55a717e83040
> <MultiXactOffsetCtlData>, allow_redirtied=allow_redirtied@entry=false) at
> ./build/../src/backend/access/transam/slru.c:1174
> #6  0x000055a717727b6f in RecordNewMultiXact (multi=79871, offset=218449,
> nmembers=2, members=members@entry=0x7f20de6831ec) at
> ./build/../src/backend/access/transam/multixact.c:944
> #7  0x000055a71772a983 in multixact_redo (record=0x55a73a8d0fc8) at
> ./build/../src/backend/access/transam/multixact.c:3464
> #8  0x000055a71774d9b8 in ApplyWalRecord (xlogreader=<optimized out>,
> record=0x7f20de6831b0, replayTLI=<synthetic pointer>) at
> ./build/../src/backend/access/transam/xlogrecovery.c:1951
> #9  PerformWalRecovery () at
> ./build/../src/backend/access/transam/xlogrecovery.c:1782
> #10 0x000055a717740def in StartupXLOG () at
> ./build/../src/backend/access/transam/xlog.c:5452
> #11 0x000055a71797c7e4 in StartupProcessMain () at
> ./build/../src/backend/postmaster/startup.c:282
> #12 0x000055a717972b20 in AuxiliaryProcessMain (auxtype=auxtype@entry=StartupProcess)
> at ./build/../src/backend/postmaster/auxprocess.c:141
> #13 0x000055a717977db3 in StartChildProcess (type=StartupProcess) at
> ./build/../src/backend/postmaster/postmaster.c:5381
> #14 0x000055a71797bfb8 in PostmasterMain (argc=argc@entry=1,
> argv=argv@entry=0x55a73a8d0590) at
> ./build/../src/backend/postmaster/postmaster.c:1463
> #15 0x000055a7176a05bc in main (argc=1, argv=0x55a73a8d0590) at
> ./build/../src/backend/main/main.c:200
>
> and WAL dump
>
> rmgr: Btree       len (rec/tot):     64/    64, tx:     336098, lsn:
> 1/32DE75F0, prev 1/32DE7580, desc: INSERT_LEAF off: 244, blkref #0: rel
> 1663/16384/16432 blk 536
> rmgr: MultiXact   len (rec/tot):     54/    54, tx:     336098, lsn:
> 1/32DE7630, prev 1/32DE75F0, desc: CREATE_ID 79871 offset 218449 nmembers
> 2: 336089 (keysh)
> 336098 (keysh)
> rmgr: Heap        len (rec/tot):     54/    54, tx:     336098, lsn:
> 1/32DE7668, prev 1/32DE7630, desc: LOCK xmax: 79871, off: 1, infobits:
> [IS_MULTI, LOCK_ONLY,
> KEYSHR_LOCK], flags: 0x00, blkref #0: rel 1663/16384/16418 blk 0
> rmgr: Heap        len (rec/tot):     72/    72, tx:     336096, lsn:
> 1/32DE76A0, prev 1/32DE7668, desc: HOT_UPDATE old_xmax: 336096, old_off:
> 52, old_infobits: [],
> flags: 0x20, new_xmax: 0, new_off: 149, blkref #0: rel 1663/16384/16401
> blk 22
> rmgr: Heap        len (rec/tot):     71/    71, tx:     336096, lsn:
> 1/32DE76E8, prev 1/32DE76A0, desc: HOT_UPDATE old_xmax: 336096, old_off:
> 149, old_infobits: [],
> flags: 0x60, new_xmax: 0, new_off: 209, blkref #0: rel 1663/16384/16399
> blk 6
> rmgr: Heap        len (rec/tot):     79/    79, tx:     336096, lsn:
> 1/32DE7730, prev 1/32DE76E8, desc: INSERT off: 150, flags: 0x00, blkref #0:
> rel 1663/16384/16417
> blk 741
> rmgr: Heap        len (rec/tot):     72/    72, tx:     336097, lsn:
> 1/32DE7780, prev 1/32DE7730, desc: HOT_UPDATE old_xmax: 336097, old_off:
> 243, old_infobits: [],
> flags: 0x20, new_xmax: 0, new_off: 228, blkref #0: rel 1663/16384/16401
> blk 26
> rmgr: Transaction len (rec/tot):     34/    34, tx:     336096, lsn:
> 1/32DE77C8, prev 1/32DE7780, desc: COMMIT 2026-05-21 08:43:07.003572 UTC
>
> Radim
>

Thanks for the additional backtrace and WAL dump.  That makes the failure
mode much clearer.

The latest trace shows the startup process here:

  SimpleLruWriteAll(MultiXactOffsetCtl, false)
  RecordNewMultiXact(multi=79871, offset=218449, nmembers=2, ...)
  multixact_redo()

The WAL dump also shows the matching record:

  rmgr: MultiXact ... desc: CREATE_ID 79871 offset 218449 nmembers 2

79871 is the last multixact on its offsets page, so replaying that record
enters the next_pageno != pageno compatibility path added by 77dff5d937b.

On REL_14 through REL_16, RecordNewMultiXact() already holds
MultiXactOffsetSLRULock while executing that code.  SimpleLruWriteAll() then
tries to acquire MultiXactOffsetCtl's SLRU control lock, which is the same
MultiXactOffsetSLRULock on those branches.  That explains the standby
startup
process waiting forever on LWLock:MultiXactOffsetSLRU, with no corresponding
SLRU I/O activity.

I think the right fix is to remove that SimpleLruWriteAll() call while
keeping the missing-page initialization logic.  The flush is only meant to
make SimpleLruDoesPhysicalPageExist() see pages that exist in SLRU buffers
but have not reached disk.  In this fallback path, I don't see a way for
the tested next_pageno to be in that state: if RecordNewMultiXact() itself
initializes the page, it writes it synchronously with SimpleLruWritePage()
before setting last_initialized_offsets_page.

I attached a small patch for REL_16_STABLE.  The same self-deadlock pattern
is also present on PG 14 and 15.  PG 17 and
18 have the same compatibility call, but SLRU locking is banked
there, and RecordNewMultiXact() does not appear to hold the relevant bank
lock before calling SimpleLruWriteAll(), so I would not describe those
branches as having this exact self-deadlock, but needs more analysis.

Added both Andrey and Heikki in to-mail, since I'm not sure if this
is more extreme than the multixact offset issue we had with 16.12, or it
is at par with that.

Regards,
Ayush

--0000000000000646a406526ad896
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 Thu, 21 May 2=
026 at 14:36, Radim Marek &lt;<a href=3D"mailto:radim@boringsql.com">radim@=
boringsql.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div>Altough the culprit is =
known, I&#39;ve got more data as requested.</div><div><br></div><div>#0 =C2=
=A00x00007f20e9bdb687 in ?? () from /lib/x86_64-linux-gnu/libc.so.6<br>#1 =
=C2=A00x00007f20e9bdbc8c in ?? () from /lib/x86_64-linux-gnu/libc.so.6<br>#=
2 =C2=A00x00007f20e9be6920 in ?? () from /lib/x86_64-linux-gnu/libc.so.6<br=
>#3 =C2=A00x000055a71796e3ca in PGSemaphoreLock (sema=3D0x7f20de6d0e38) at =
./build/src/backend/port/pg_sema.c:327<br>#4 =C2=A00x000055a7179f57ed in LW=
LockAcquire (lock=3D0x7f20de6d1800, mode=3Dmode@entry=3DLW_EXCLUSIVE) at ./=
build/../src/backend/storage/lmgr/lwlock.c:1314<br>#5 =C2=A00x000055a71772d=
fb2 in SimpleLruWriteAll (ctl=3Dctl@entry=3D0x55a717e83040 &lt;MultiXactOff=
setCtlData&gt;, allow_redirtied=3Dallow_redirtied@entry=3Dfalse) at<br>./bu=
ild/../src/backend/access/transam/slru.c:1174<br>#6 =C2=A00x000055a717727b6=
f in RecordNewMultiXact (multi=3D79871, offset=3D218449, nmembers=3D2, memb=
ers=3Dmembers@entry=3D0x7f20de6831ec) at<br>./build/../src/backend/access/t=
ransam/multixact.c:944<br>#7 =C2=A00x000055a71772a983 in multixact_redo (re=
cord=3D0x55a73a8d0fc8) at ./build/../src/backend/access/transam/multixact.c=
:3464<br>#8 =C2=A00x000055a71774d9b8 in ApplyWalRecord (xlogreader=3D&lt;op=
timized out&gt;, record=3D0x7f20de6831b0, replayTLI=3D&lt;synthetic pointer=
&gt;) at<br>./build/../src/backend/access/transam/xlogrecovery.c:1951<br>#9=
 =C2=A0PerformWalRecovery () at ./build/../src/backend/access/transam/xlogr=
ecovery.c:1782<br>#10 0x000055a717740def in StartupXLOG () at ./build/../sr=
c/backend/access/transam/xlog.c:5452<br>#11 0x000055a71797c7e4 in StartupPr=
ocessMain () at ./build/../src/backend/postmaster/startup.c:282<br>#12 0x00=
0055a717972b20 in AuxiliaryProcessMain (auxtype=3Dauxtype@entry=3DStartupPr=
ocess) at ./build/../src/backend/postmaster/auxprocess.c:141<br>#13 0x00005=
5a717977db3 in StartChildProcess (type=3DStartupProcess) at ./build/../src/=
backend/postmaster/postmaster.c:5381<br>#14 0x000055a71797bfb8 in Postmaste=
rMain (argc=3Dargc@entry=3D1, argv=3Dargv@entry=3D0x55a73a8d0590) at ./buil=
d/../src/backend/postmaster/postmaster.c:1463<br>#15 0x000055a7176a05bc in =
main (argc=3D1, argv=3D0x55a73a8d0590) at ./build/../src/backend/main/main.=
c:200</div><div><br></div></div><div>and WAL dump<br><br>rmgr: Btree =C2=A0=
 =C2=A0 =C2=A0 len (rec/tot): =C2=A0 =C2=A0 64/ =C2=A0 =C2=A064, tx: =C2=A0=
 =C2=A0 336098, lsn: 1/32DE75F0, prev 1/32DE7580, desc: INSERT_LEAF off: 24=
4, blkref #0: rel 1663/16384/16432 blk 536<br>rmgr: MultiXact =C2=A0 len (r=
ec/tot): =C2=A0 =C2=A0 54/ =C2=A0 =C2=A054, tx: =C2=A0 =C2=A0 336098, lsn: =
1/32DE7630, prev 1/32DE75F0, desc: CREATE_ID 79871 offset 218449 nmembers 2=
: 336089 (keysh)<br>336098 (keysh)<br>rmgr: Heap =C2=A0 =C2=A0 =C2=A0 =C2=
=A0len (rec/tot): =C2=A0 =C2=A0 54/ =C2=A0 =C2=A054, tx: =C2=A0 =C2=A0 3360=
98, lsn: 1/32DE7668, prev 1/32DE7630, desc: LOCK xmax: 79871, off: 1, infob=
its: [IS_MULTI, LOCK_ONLY,<br>KEYSHR_LOCK], flags: 0x00, blkref #0: rel 166=
3/16384/16418 blk 0<br>rmgr: Heap =C2=A0 =C2=A0 =C2=A0 =C2=A0len (rec/tot):=
 =C2=A0 =C2=A0 72/ =C2=A0 =C2=A072, tx: =C2=A0 =C2=A0 336096, lsn: 1/32DE76=
A0, prev 1/32DE7668, desc: HOT_UPDATE old_xmax: 336096, old_off: 52, old_in=
fobits: [],<br>flags: 0x20, new_xmax: 0, new_off: 149, blkref #0: rel 1663/=
16384/16401 blk 22<br>rmgr: Heap =C2=A0 =C2=A0 =C2=A0 =C2=A0len (rec/tot): =
=C2=A0 =C2=A0 71/ =C2=A0 =C2=A071, tx: =C2=A0 =C2=A0 336096, lsn: 1/32DE76E=
8, prev 1/32DE76A0, desc: HOT_UPDATE old_xmax: 336096, old_off: 149, old_in=
fobits: [],<br>flags: 0x60, new_xmax: 0, new_off: 209, blkref #0: rel 1663/=
16384/16399 blk 6<br>rmgr: Heap =C2=A0 =C2=A0 =C2=A0 =C2=A0len (rec/tot): =
=C2=A0 =C2=A0 79/ =C2=A0 =C2=A079, tx: =C2=A0 =C2=A0 336096, lsn: 1/32DE773=
0, prev 1/32DE76E8, desc: INSERT off: 150, flags: 0x00, blkref #0: rel 1663=
/16384/16417<br>blk 741<br>rmgr: Heap =C2=A0 =C2=A0 =C2=A0 =C2=A0len (rec/t=
ot): =C2=A0 =C2=A0 72/ =C2=A0 =C2=A072, tx: =C2=A0 =C2=A0 336097, lsn: 1/32=
DE7780, prev 1/32DE7730, desc: HOT_UPDATE old_xmax: 336097, old_off: 243, o=
ld_infobits: [],<br>flags: 0x20, new_xmax: 0, new_off: 228, blkref #0: rel =
1663/16384/16401 blk 26<br>rmgr: Transaction len (rec/tot): =C2=A0 =C2=A0 3=
4/ =C2=A0 =C2=A034, tx: =C2=A0 =C2=A0 336096, lsn: 1/32DE77C8, prev 1/32DE7=
780, desc: COMMIT 2026-05-21 08:43:07.003572 UTC<br><br></div><div>Radim</d=
iv></div></blockquote><div><br></div>Thanks for the additional backtrace an=
d WAL dump.=C2=A0 That makes the failure<br>mode much clearer.<br><br>The l=
atest trace shows the startup process here:<br><br>=C2=A0 SimpleLruWriteAll=
(MultiXactOffsetCtl, false)<br>=C2=A0 RecordNewMultiXact(multi=3D79871, off=
set=3D218449, nmembers=3D2, ...)<br>=C2=A0 multixact_redo()<br><br>The WAL =
dump also shows the matching record:<br><br>=C2=A0 rmgr: MultiXact ... desc=
: CREATE_ID 79871 offset 218449 nmembers 2<br><br>79871 is the last multixa=
ct on its offsets page, so replaying that record<br><div>enters the next_pa=
geno !=3D pageno compatibility path added by 77dff5d937b.=C2=A0</div><div><=
br></div><div>On REL_14 through REL_16, RecordNewMultiXact() already holds<=
br>MultiXactOffsetSLRULock while executing that code.=C2=A0 SimpleLruWriteA=
ll() then<br>tries to acquire MultiXactOffsetCtl&#39;s SLRU control lock, w=
hich is the same<br>MultiXactOffsetSLRULock on those branches.=C2=A0 That e=
xplains the standby startup<br>process waiting forever on LWLock:MultiXactO=
ffsetSLRU, with no corresponding<br>SLRU I/O activity.=C2=A0<br><br>I think=
 the right fix is to remove that SimpleLruWriteAll() call while<br>keeping =
the missing-page initialization logic.=C2=A0 The flush is only meant to<br>=
make SimpleLruDoesPhysicalPageExist() see pages that exist in SLRU buffers<=
br>but have not reached disk.=C2=A0 In this fallback path, I don&#39;t see =
a way for<br>the tested next_pageno to be in that state: if RecordNewMultiX=
act() itself<br>initializes the page, it writes it synchronously with Simpl=
eLruWritePage()<br>before setting last_initialized_offsets_page.<br><br>I a=
ttached a small patch for REL_16_STABLE.=C2=A0 The same self-deadlock patte=
rn<br>is also present on PG 14 and 15.=C2=A0 PG 17 and<br>18 have the same =
compatibility call, but SLRU locking is banked<br>there, and RecordNewMulti=
Xact() does not appear to hold the relevant bank<br>lock before calling Sim=
pleLruWriteAll(), so I would not describe those<br>branches as having this =
exact self-deadlock, but needs more analysis.</div><div><br></div><div>Adde=
d both Andrey and Heikki in to-mail, since I&#39;m not sure if this</div><d=
iv>is more extreme than the multixact offset issue we had with 16.12, or it=
</div><div>is at par with that.</div><div><br></div><div>Regards,<br>Ayush<=
/div></div></div>

--0000000000000646a406526ad896--

--0000000000000646a506526ad898
Content-Type: application/octet-stream;
	name="v1-0001-Avoid-self-deadlock-on-MultiXactOffsetSLRULock-dur.patch"
Content-Disposition: attachment;
	filename="v1-0001-Avoid-self-deadlock-on-MultiXactOffsetSLRULock-dur.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mph5d2hw0>
X-Attachment-Id: f_mph5d2hw0

RnJvbSBiMzNhYmVlZGUwODQ3ZWRhYzM2MDNiODdhNDc4YTgzMmJlMTc4NGY4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBeXVzaCBUaXdhcmkgPGF5dXNodGl3YXJpLnNsZzAxQGdtYWls
LmNvbT4KRGF0ZTogVGh1LCAyMSBNYXkgMjAyNiAwNzozOToyOCArMDAwMApTdWJqZWN0OiBbUEFU
Q0ggUkVMXzE2X1NUQUJMRSB2MV0gQXZvaWQgc2VsZi1kZWFkbG9jayBvbgogTXVsdGlYYWN0T2Zm
c2V0U0xSVUxvY2sgZHVyaW5nIFdBTCByZXBsYXkKCkNvbW1pdCA3N2RmZjVkOTM3YiBhZGRlZCBh
IGNvbXBhdGliaWxpdHkgY2hlY2sgaW4gUmVjb3JkTmV3TXVsdGlYYWN0KCkKdGhhdCBjYW4gY2Fs
bCBTaW1wbGVMcnVXcml0ZUFsbChNdWx0aVhhY3RPZmZzZXRDdGwsIGZhbHNlKSB3aGlsZSBhbHJl
YWR5CmhvbGRpbmcgTXVsdGlYYWN0T2Zmc2V0U0xSVUxvY2suICBJbiBSRUxfMTYsIFNpbXBsZUxy
dVdyaXRlQWxsKCkgdHJpZXMKdG8gYWNxdWlyZSB0aGUgc2FtZSBTTFJVIGNvbnRyb2wgbG9jaywg
c28gV0FMIHJlcGxheSBjYW4gc2VsZi1kZWFkbG9jawp3aXRoIHRoZSBzdGFydHVwIHByb2Nlc3Mg
d2FpdGluZyBvbiBMV0xvY2s6TXVsdGlYYWN0T2Zmc2V0U0xSVS4KClRoZSBmbHVzaCBpcyBub3Qg
bmVlZGVkIGZvciB0aGUgcGFnZSB0ZXN0ZWQgaW4gdGhpcyBmYWxsYmFjayBwYXRoLiAgSWYKUmVj
b3JkTmV3TXVsdGlYYWN0KCkgaW5pdGlhbGl6ZXMgdGhhdCBvZmZzZXRzIHBhZ2UsIGl0IHdyaXRl
cyBpdApzeW5jaHJvbm91c2x5IHdpdGggU2ltcGxlTHJ1V3JpdGVQYWdlKCkgYmVmb3JlIHVwZGF0
aW5nCmxhc3RfaW5pdGlhbGl6ZWRfb2Zmc2V0c19wYWdlLiAgRHJvcCB0aGUgdW5zYWZlIGZsdXNo
IGFuZCBrZWVwIHRoZQpleGlzdGluZyBtaXNzaW5nLXBhZ2UgaW5pdGlhbGl6YXRpb24gbG9naWMu
CgpSZXBvcnRlZC1ieTogUmFkaW0gTWFyZWsgPHJhZGltQGJvcmluZ3NxbC5jb20+ClJlcG9ydGVk
LWJ5OiBNYXJrbyBUaWlra2FqYSA8bWFya29Aam9oLnRvPgpEaWFnbm9zZWQtYnk6IEFuZHJleSBC
b3JvZGluIDx4NG1tbUB5YW5kZXgtdGVhbS5ydT4KRGlzY3Vzc2lvbjogaHR0cHM6Ly9wb3N0Z3Iu
ZXMvbS8xOTQ5MC05YzU5YzZhNTgzNTEzYjk5QHBvc3RncmVzcWwub3JnCi0tLQogc3JjL2JhY2tl
bmQvYWNjZXNzL3RyYW5zYW0vbXVsdGl4YWN0LmMgfCAxMyArKysrKysrLS0tLS0tCiAxIGZpbGUg
Y2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3Ny
Yy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL211bHRpeGFjdC5jIGIvc3JjL2JhY2tlbmQvYWNjZXNz
L3RyYW5zYW0vbXVsdGl4YWN0LmMKaW5kZXggZjgyNTU3OWU4ODguLjViNmI0OGViNzljIDEwMDY0
NAotLS0gYS9zcmMvYmFja2VuZC9hY2Nlc3MvdHJhbnNhbS9tdWx0aXhhY3QuYworKysgYi9zcmMv
YmFja2VuZC9hY2Nlc3MvdHJhbnNhbS9tdWx0aXhhY3QuYwpAQCAtOTM0LDE2ICs5MzQsMTcgQEAg
UmVjb3JkTmV3TXVsdGlYYWN0KE11bHRpWGFjdElkIG11bHRpLCBNdWx0aVhhY3RPZmZzZXQgb2Zm
c2V0LAogCQkgKiBzZWVuIGFueSBYTE9HX01VTFRJWEFDVF9aRVJPX09GRl9QQUdFIHJlY29yZHMg
eWV0LCB3aGljaCBzaG91bGQKIAkJICogaGFwcGVuIGF0IG1vc3Qgb25jZSBhZnRlciBzdGFydGlu
ZyBXQUwgcmVjb3ZlcnkuCiAJCSAqCi0JCSAqIEFzIGFuIGV4dHJhIHNhZmV0eSBtZWFzdXJlLCBp
ZiB3ZSBkbyByZXNvcnQgdG8KLQkJICogU2ltcGxlTHJ1RG9lc1BoeXNpY2FsUGFnZUV4aXN0KCks
IGZsdXNoIHRoZSBTTFJVIGJ1ZmZlcnMgZmlyc3Qgc28KLQkJICogdGhhdCBpdCB3aWxsIHJldHVy
biBhbiBhY2N1cmF0ZSByZXN1bHQuCisJCSAqCisJCSAqIFdlIGNhbm5vdCBjYWxsIFNpbXBsZUxy
dVdyaXRlQWxsKCkgdG8gZmx1c2ggdGhlIFNMUlUgYnVmZmVycworCQkgKiBoZXJlLCBiZWNhdXNl
IHRoYXQgd291bGQgc2VsZi1kZWFkbG9jayBvbiBNdWx0aVhhY3RPZmZzZXRTTFJVTG9jaywKKwkJ
ICogd2hpY2ggd2UgYWxyZWFkeSBob2xkLiAgRm9ydHVuYXRlbHkgd2UgZG8gbm90IG5lZWQgdG86
IGV2ZXJ5CisJCSAqIHBhZ2UgdGhhdCB0aGlzIGNvZGUgcGF0aCBpbml0aWFsaXplcyBpcyBzeW5j
aHJvbm91c2x5IGZsdXNoZWQgdmlhCisJCSAqIFNpbXBsZUxydVdyaXRlUGFnZSgpIGJlbG93IGJl
Zm9yZSB0aGlzIGxvY2sgaXMgcmVsZWFzZWQsIHNvIHRoZXJlCisJCSAqIGFyZSBubyByZWxldmFu
dCBkaXJ0eSBwYWdlcy4KIAkJICotLS0tLS0tLS0tCiAJCSAqLwogCQlpZiAobGFzdF9pbml0aWFs
aXplZF9vZmZzZXRzX3BhZ2UgPT0gLTEpCi0JCXsKLQkJCVNpbXBsZUxydVdyaXRlQWxsKE11bHRp
WGFjdE9mZnNldEN0bCwgZmFsc2UpOwogCQkJaW5pdF9uZWVkZWQgPSAhU2ltcGxlTHJ1RG9lc1Bo
eXNpY2FsUGFnZUV4aXN0KE11bHRpWGFjdE9mZnNldEN0bCwgbmV4dF9wYWdlbm8pOwotCQl9CiAJ
CWVsc2UKIAkJCWluaXRfbmVlZGVkID0gKGxhc3RfaW5pdGlhbGl6ZWRfb2Zmc2V0c19wYWdlID09
IHBhZ2Vubyk7CiAKLS0gCjIuNDMuMAoK
--0000000000000646a506526ad898--