Feedback-ID: i0c21471d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
MIME-Version: 1.0
Message-Id: <b1f0f8c7-8f01-4950-af77-339df3dc4684@app.fastmail.com>
In-Reply-To: <68de6498-0449-a113-dd03-e198dded0bac@gmail.com>
References: <9a9c7e65-c47b-4400-a63e-ac6169c0860e@app.fastmail.com>
 <CAA4eK1JJq_ER6Kq_H=jKHR75QPRd8y9_D=RtYw=aPYKMfqLi9A@mail.gmail.com>
 <CAA4eK1KdCb+5sjYu6qCMXXdCX1y_ihr8kFzMozq0=P=auYxgog@mail.gmail.com>
 <CANhcyEV6q1Vhd37i1axUeScLi0UAGVxta1LDa0BV0Eh--TcPMg@mail.gmail.com>
 <CAA4eK1JaQcAZ=n513-4VDW4ujE9T9f007fczNCpVDbg1smhT4g@mail.gmail.com>
 <5da4b286-e570-4341-8262-92d763f6b1a4@app.fastmail.com>
 <776c5cac-5ef5-4001-b1bc-5b698bc0c62a@app.fastmail.com>
 <3c024250-3f13-4f4d-b8e9-55f176db4abf@eisentraut.org>
 <0dffca12-bf17-4a7a-334d-225569de5e6e@gmail.com>
 <OSBPR01MB25528300C71FDD83EA1DCA12F5DD2@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1+Qmc34cooSNm2=U6YsySSjZTn2_eD_deDFEAZv+aj-AA@mail.gmail.com>
 <OSBPR01MB2552440DCE1AE5EDC51BAEC6F5DD2@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1J9Vn1HB7sXNx-cH4COBd_moGZtrZd82Z160mK6u0HspQ@mail.gmail.com>
 <bde6ac67-69cc-c104-5ab6-dd4f5deadf24@gmail.com>
 <CAA4eK1KG7+jUdONhsELY2poyBrmesNnkt-m5QSgPhgyyM6cFHQ@mail.gmail.com>
 <68de6498-0449-a113-dd03-e198dded0bac@gmail.com>
Date: Thu, 11 Jul 2024 20:24:36 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Alexander Lakhin" <exclusion@gmail.com>,
 "Amit Kapila" <amit.kapila16@gmail.com>,
 "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: speed up a logical replica setup
Content-Type: multipart/mixed;
 boundary=b0b4a1af8735438983cab8c666b66488
Archived-At: <https://www.postgresql.org/message-id/b1f0f8c7-8f01-4950-af77-339df3dc4684%40app.fastmail.com>
Precedence: bulk

--b0b4a1af8735438983cab8c666b66488
Content-Type: multipart/alternative;
 boundary=67056cf5165f487ca2e4e85395f9daa5

--67056cf5165f487ca2e4e85395f9daa5
Content-Type: text/plain

On Thu, Jul 11, 2024, at 2:00 PM, Alexander Lakhin wrote:
> Hello Amit and Hou-San,
> 
> 11.07.2024 13:21, Amit Kapila wrote:
> >
> > We don't wait for the xmin to catch up corresponding to this insert
> > and I don't know if there is a way to do that. So, we should move this
> > Insert to after the call to pg_sync_replication_slots(). It won't
> > impact the general test of pg_createsubscriber.
> >
> > Thanks to Hou-San for helping me in the analysis of this BF failure.
> 
> Thank you for investigating that issue!
> 
> May I ask you to look at another failure of the test occurred today [1]?
> 

Thanks for the report!

You are observing the same issue that Amit explained in [1]. The
pg_create_logical_replication_slot returns the EndRecPtr (see
slot->data.confirmed_flush in DecodingContextFindStartpoint()). EndRecPtr points
to the next record and it is a future position for an idle server. That's why
the recovery takes some time to finish because it is waiting for an activity to
increase the LSN position. Since you modified LOG_SNAPSHOT_INTERVAL_MS to create
additional WAL records soon, the EndRecPtr position is reached rapidly and the
recovery ends quickly.

Hayato proposes a patch [2] to create an additional WAL record that has the same
effect from you little hack: increase the LSN position to allow the recovery
finishes soon. I don't like the solution although it seems simple to implement.
As Amit said if we know the ReadRecPtr, we could use it as consistent LSN. The
problem is that it is used by logical decoding but it is not exposed. [reading
the code...] When the logical replication slot is created, restart_lsn points to
the lastReplayedEndRecPtr (see ReplicationSlotReserveWal()) that is the last
record replayed. Since the replication slots aren't in use, we could use the
restart_lsn from the last replication slot as a consistent LSN.

I'm attaching a patch that implements it.It runs in 6s instead of 26s.


[1] https://www.postgresql.org/message-id/CAA4eK1%2Bp%2B7Ag6nqdFRdqowK1EmJ6bG-MtZQ_54dnFBi%3D_OO5RQ%40mail.gmail.com
[2] https://www.postgresql.org/message-id/OSBPR01MB25521B15BF950D2523BBE143F5D32%40OSBPR01MB2552.jpnprd01.prod.outlook.com


--
Euler Taveira
EDB   https://www.enterprisedb.com/

--67056cf5165f487ca2e4e85395f9daa5
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Jul 11,=
 2024, at 2:00 PM, Alexander Lakhin wrote:<br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><div>Hello Amit and Hou-San,<br></div><div><b=
r></div><div>11.07.2024 13:21, Amit Kapila wrote:<br></div><div>&gt;<br>=
</div><div>&gt; We don't wait for the xmin to catch up corresponding to =
this insert<br></div><div>&gt; and I don't know if there is a way to do =
that. So, we should move this<br></div><div>&gt; Insert to after the cal=
l to pg_sync_replication_slots(). It won't<br></div><div>&gt; impact the=
 general test of pg_createsubscriber.<br></div><div>&gt;<br></div><div>&=
gt; Thanks to Hou-San for helping me in the analysis of this BF failure.=
<br></div><div><br></div><div>Thank you for investigating that issue!<br=
></div><div><br></div><div>May I ask you to look at another failure of t=
he test occurred today [1]?<br></div><div><br></div></blockquote><div><b=
r></div><div>Thanks for the report!<br></div><div><br></div><div>You are=
 observing the same issue that Amit explained in [1]. The<br></div><div>=
pg_create_logical_replication_slot returns the EndRecPtr (see<br></div><=
div>slot-&gt;data.confirmed_flush in DecodingContextFindStartpoint()). E=
ndRecPtr points<br></div><div>to the next record and it is a future posi=
tion for an idle server. That's why<br></div><div>the recovery takes som=
e time to finish because it is waiting for an activity to<br></div><div>=
increase the LSN position. Since you modified LOG_SNAPSHOT_INTERVAL_MS t=
o create<br></div><div>additional WAL records soon, the EndRecPtr positi=
on is reached rapidly and the<br></div><div>recovery ends quickly.<br></=
div><div><br></div><div>Hayato proposes a patch [2] to create an additio=
nal WAL record that has the same<br></div><div>effect from you little ha=
ck: increase the LSN position to allow the recovery<br></div><div>finish=
es soon. I don't like the solution although it seems simple to implement=
.<br></div><div>As Amit said if we know the ReadRecPtr, we could use it =
as consistent LSN. The<br></div><div>problem is that it is used by logic=
al decoding but it is not exposed. [reading<br></div><div>the code...] W=
hen the logical replication slot is created, restart_lsn points to<br></=
div><div>the lastReplayedEndRecPtr (see ReplicationSlotReserveWal()) tha=
t is the last<br></div><div>record replayed. Since the replication slots=
 aren't in use, we could use the<br></div><div>restart_lsn from the last=
 replication slot as a consistent LSN.<br></div><div><br></div><div>I'm =
attaching a patch that implements it.It runs in 6s instead of 26s.<br></=
div><div><br></div><div><br></div><div>[1] <a href=3D"https://www.postgr=
esql.org/message-id/CAA4eK1%2Bp%2B7Ag6nqdFRdqowK1EmJ6bG-MtZQ_54dnFBi%3D_=
OO5RQ%40mail.gmail.com">https://www.postgresql.org/message-id/CAA4eK1%2B=
p%2B7Ag6nqdFRdqowK1EmJ6bG-MtZQ_54dnFBi%3D_OO5RQ%40mail.gmail.com</a><br>=
</div><div>[2] <a href=3D"https://www.postgresql.org/message-id/OSBPR01M=
B25521B15BF950D2523BBE143F5D32%40OSBPR01MB2552.jpnprd01.prod.outlook.com=
">https://www.postgresql.org/message-id/OSBPR01MB25521B15BF950D2523BBE14=
3F5D32%40OSBPR01MB2552.jpnprd01.prod.outlook.com</a><br></div><div><br><=
/div><div><br></div><div id=3D"sig112409080"><div class=3D"signature">--=
<br></div><div class=3D"signature">Euler Taveira<br></div><div class=3D"=
signature">EDB&nbsp;&nbsp; <a href=3D"https://www.enterprisedb.com/">htt=
ps://www.enterprisedb.com/</a><br></div></div><div><br></div></body></ht=
ml>
--67056cf5165f487ca2e4e85395f9daa5--

--b0b4a1af8735438983cab8c666b66488
Content-Disposition: attachment;
	filename*0="0001-pg_createsubscriber-fix-slow-recovery.patch"
Content-Type: text/x-patch;
	name="=?UTF-8?Q?0001-pg=5Fcreatesubscriber-fix-slow-recovery.patch?="
Content-Transfer-Encoding: BASE64

RnJvbSBhM2JlNjVjOWJlYTA4ZDNjN2ZmZDU3NTM0MmE4NzlkMzdiMjhiOWE4IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBFdWxlciBUYXZlaXJhIDxldWxlckBldWxlcnRvLmNv
bT4KRGF0ZTogVGh1LCAxMSBKdWwgMjAyNCAxOTo1OTo1NiAtMDMwMApTdWJqZWN0OiBbUEFU
Q0hdIHBnX2NyZWF0ZXN1YnNjcmliZXI6IGZpeCBzbG93IHJlY292ZXJ5CgpJZiB0aGUgcHJp
bWFyeSBzZXJ2ZXIgaXMgaWRsZSB3aGVuIHlvdSBhcmUgcnVubmluZyBwZ19jcmVhdGVzdWJz
Y3JpYmVyLAppdCB1c2VkIHRvIHRha2Ugc29tZSB0aW1lIGR1cmluZyByZWNvdmVyeS4gVGhl
IHJlYXNvbiBpcyB0aGF0IGl0IHdhcwp1c2luZyB0aGUgTFNOIHJldHVybmVkIGJ5IHBnX2Ny
ZWF0ZV9sb2dpY2FsX3JlcGxpY2F0aW9uX3Nsb3QgYXMKcmVjb3ZlcnlfdGFyZ2V0X2xzbi4g
VGhpcyBMU04gcG9pbnRzIHRvICJlbmQgKyAxIiByZWNvcmQgdGhhdCBtaWdodCBub3QKYmUg
YXZhaWxhYmxlIGF0IFdBTCwgaGVuY2UsIHRoZSByZWNvdmVyeSByb3V0aW5lIHdhaXRzIHVu
dGlsIHNvbWUKYWN0aXZpdHkgZnJvbSBhdXhpbGlhcnkgcHJvY2Vzc2VzIHdyaXRlIFdBTCBy
ZWNvcmRzIGFuZCBvbmNlIGl0IHJlYWNoZXMKdGhlIHJlY292ZXJ5X3RhcmdldF9sc24gcG9z
aXRpb24uCgpJbnN0ZWFkLCB1c2UgcmVzdGFydF9sc24gZnJvbSB0aGUgbGFzdCByZXBsaWNh
dGlvbiBzbG90LiBJdCBwb2ludHMgdG8KdGhlIGxhc3QgV0FMIHJlY29yZCB0aGF0IHdhcyBy
ZXBsYXllZC4gSGVuY2UsIHRoZSByZWNvdmVyeSBmaW5pc2hlcwpzb29uLgoKY3JlYXRlX2xv
Z2ljYWxfcmVwbGljYXRpb25fc2xvdCgpIGRvZXMgbm90IHJldHVybiBMU04gc28gY2hhbmdl
IGl0cwpzaWduYXR1cmUuCgpEaXNjdXNzaW9uOiBodHRwczovL3d3dy5wb3N0Z3Jlc3FsLm9y
Zy9tZXNzYWdlLWlkLzIzNzczMTkuMTcxOTc2Njc5NCU0MHNzcy5wZ2gucGEudXMKRGlzY3Vz
c2lvbjogaHR0cHM6Ly93d3cucG9zdGdyZXNxbC5vcmcvbWVzc2FnZS1pZC82OGRlNjQ5OC0w
NDQ5LWExMTMtZGQwMy1lMTk4ZGRlZDBiYWMlNDBnbWFpbC5jb20KLS0tCiBzcmMvYmluL3Bn
X2Jhc2ViYWNrdXAvcGdfY3JlYXRlc3Vic2NyaWJlci5jIHwgNTYgKysrKysrKysrKysrKysr
Ky0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNDMgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25z
KC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2Jpbi9wZ19iYXNlYmFja3VwL3BnX2NyZWF0ZXN1YnNj
cmliZXIuYyBiL3NyYy9iaW4vcGdfYmFzZWJhY2t1cC9wZ19jcmVhdGVzdWJzY3JpYmVyLmMK
aW5kZXggMjFkZDUwZjgwODkuLjVlZjNmNzUxYTViIDEwMDY0NAotLS0gYS9zcmMvYmluL3Bn
X2Jhc2ViYWNrdXAvcGdfY3JlYXRlc3Vic2NyaWJlci5jCisrKyBiL3NyYy9iaW4vcGdfYmFz
ZWJhY2t1cC9wZ19jcmVhdGVzdWJzY3JpYmVyLmMKQEAgLTg2LDggKzg2LDggQEAgc3RhdGlj
IHZvaWQgc2V0dXBfcmVjb3ZlcnkoY29uc3Qgc3RydWN0IExvZ2ljYWxSZXBJbmZvICpkYmlu
Zm8sIGNvbnN0IGNoYXIgKmRhdGEKIHN0YXRpYyB2b2lkIGRyb3BfcHJpbWFyeV9yZXBsaWNh
dGlvbl9zbG90KHN0cnVjdCBMb2dpY2FsUmVwSW5mbyAqZGJpbmZvLAogCQkJCQkJCQkJCSAg
Y29uc3QgY2hhciAqc2xvdG5hbWUpOwogc3RhdGljIHZvaWQgZHJvcF9mYWlsb3Zlcl9yZXBs
aWNhdGlvbl9zbG90cyhzdHJ1Y3QgTG9naWNhbFJlcEluZm8gKmRiaW5mbyk7Ci1zdGF0aWMg
Y2hhciAqY3JlYXRlX2xvZ2ljYWxfcmVwbGljYXRpb25fc2xvdChQR2Nvbm4gKmNvbm4sCi0J
CQkJCQkJCQkJCSBzdHJ1Y3QgTG9naWNhbFJlcEluZm8gKmRiaW5mbyk7CitzdGF0aWMgYm9v
bCBjcmVhdGVfbG9naWNhbF9yZXBsaWNhdGlvbl9zbG90KFBHY29ubiAqY29ubiwKKwkJCQkJ
CQkJCQkJc3RydWN0IExvZ2ljYWxSZXBJbmZvICpkYmluZm8pOwogc3RhdGljIHZvaWQgZHJv
cF9yZXBsaWNhdGlvbl9zbG90KFBHY29ubiAqY29ubiwgc3RydWN0IExvZ2ljYWxSZXBJbmZv
ICpkYmluZm8sCiAJCQkJCQkJCSAgY29uc3QgY2hhciAqc2xvdF9uYW1lKTsKIHN0YXRpYyB2
b2lkIHBnX2N0bF9zdGF0dXMoY29uc3QgY2hhciAqcGdfY3RsX2NtZCwgaW50IHJjKTsKQEAg
LTc2OSwxNSArNzY5LDQ3IEBAIHNldHVwX3B1Ymxpc2hlcihzdHJ1Y3QgTG9naWNhbFJlcElu
Zm8gKmRiaW5mbykKIAkJY3JlYXRlX3B1YmxpY2F0aW9uKGNvbm4sICZkYmluZm9baV0pOwog
CiAJCS8qIENyZWF0ZSByZXBsaWNhdGlvbiBzbG90IG9uIHB1Ymxpc2hlciAqLwotCQlpZiAo
bHNuKQotCQkJcGdfZnJlZShsc24pOwotCQlsc24gPSBjcmVhdGVfbG9naWNhbF9yZXBsaWNh
dGlvbl9zbG90KGNvbm4sICZkYmluZm9baV0pOwotCQlpZiAobHNuICE9IE5VTEwgfHwgZHJ5
X3J1bikKKwkJaWYgKGNyZWF0ZV9sb2dpY2FsX3JlcGxpY2F0aW9uX3Nsb3QoY29ubiwgJmRi
aW5mb1tpXSkgfHwgZHJ5X3J1bikKIAkJCXBnX2xvZ19pbmZvKCJjcmVhdGUgcmVwbGljYXRp
b24gc2xvdCBcIiVzXCIgb24gcHVibGlzaGVyIiwKIAkJCQkJCWRiaW5mb1tpXS5yZXBsc2xv
dG5hbWUpOwogCQllbHNlCiAJCQlleGl0KDEpOwogCisJCS8qCisJCSAqIEdldCByZXN0YXJ0
X2xzbiBmcm9tIHRoZSBsYXN0IHJlcGxpY2F0aW9uIHNsb3QuIEl0IHBvaW50cyB0byB0aGUK
KwkJICogbGFzdCByZWNvcmQgcmVwbGF5ZWQuIFRoZSBMU04gcmV0dXJuZWQgYnkKKwkJICog
cGdfY3JlYXRlX2xvZ2ljYWxfcmVwbGljYXRpb25fc2xvdCgpIHNob3VsZCBub3QgYmUgdXNl
ZCBiZWNhdXNlIGl0CisJCSAqIHBvaW50cyB0byBhIGZ1dHVyZSBwb3NpdGlvbi4gSW4gY2Fz
ZSB0aGUgc2VydmVyIGlzIGlkbGUgd2hpbGUKKwkJICogcnVubmluZyB0aGlzIHRvb2wsIHRo
ZSByZWNvdmVyeSB3aWxsIG5vdCBmaW5pc2ggc29vbiBiZWNhdXNlIHRoZQorCQkgKiBmdXR1
cmUgcG9zaXRpb24gd2FzIG5vdCByZWFjaGVkLiBIZW5jZSwgb2J0YWluIHRoZSByZXN0YXJ0
X2xzbiB0aGF0CisJCSAqIHBvaW50cyB0byBhIExTTiBhbHJlYWR5IGF2YWlsYWJsZSBhdCBX
QUwuIFRoZSByZWNvdmVyeSBwYXJhbWV0ZXJzCisJCSAqIGd1YXJhbnRlZSB0aGF0IHRoaXMg
bGFzdCByZXBsaWNhdGlvbiBzbG90IHdpbGwgYmUgYXBwbGllZC4KKwkJICovCisJCWlmICgo
aSA9PSBudW1fZGJzIC0gMSkgJiYgIWRyeV9ydW4pCisJCXsKKwkJCVBRRXhwQnVmZmVyIHN0
ciA9IGNyZWF0ZVBRRXhwQnVmZmVyKCk7CisJCQlQR3Jlc3VsdCAgICpyZXM7CisKKwkJCWFw
cGVuZFBRRXhwQnVmZmVyKHN0ciwKKwkJCQkJCQkgICJTRUxFQ1QgcmVzdGFydF9sc24gRlJP
TSBwZ19jYXRhbG9nLnBnX3JlcGxpY2F0aW9uX3Nsb3RzICIKKwkJCQkJCQkgICJXSEVSRSBz
bG90X25hbWUgPSAnJXMnIiwKKwkJCQkJCQkgIGRiaW5mb1tpXS5yZXBsc2xvdG5hbWUpOwor
CQkJcmVzID0gUFFleGVjKGNvbm4sIHN0ci0+ZGF0YSk7CisJCQlpZiAoUFFyZXN1bHRTdGF0
dXMocmVzKSAhPSBQR1JFU19UVVBMRVNfT0spCisJCQl7CisJCQkJcGdfbG9nX2Vycm9yKCJj
b3VsZCBub3Qgb2J0YWluIGNvbnNpc3RlbnQgTFNOOiAlcyIsCisJCQkJCQkJIFBRcmVzdWx0
RXJyb3JNZXNzYWdlKHJlcykpOworCQkJCWRpc2Nvbm5lY3RfZGF0YWJhc2UoY29ubiwgdHJ1
ZSk7CisJCQl9CisJCQllbHNlCisJCQl7CisJCQkJbHNuID0gcGdfc3RyZHVwKFBRZ2V0dmFs
dWUocmVzLCAwLCAwKSk7CisJCQl9CisKKwkJCVBRY2xlYXIocmVzKTsKKwkJCWRlc3Ryb3lQ
UUV4cEJ1ZmZlcihzdHIpOworCQl9CisKIAkJZGlzY29ubmVjdF9kYXRhYmFzZShjb25uLCBm
YWxzZSk7CiAJfQogCkBAIC0xMjgzLDE5ICsxMzE1LDE4IEBAIGRyb3BfZmFpbG92ZXJfcmVw
bGljYXRpb25fc2xvdHMoc3RydWN0IExvZ2ljYWxSZXBJbmZvICpkYmluZm8pCiB9CiAKIC8q
Ci0gKiBDcmVhdGUgYSBsb2dpY2FsIHJlcGxpY2F0aW9uIHNsb3QgYW5kIHJldHVybnMgYSBM
U04uCisgKiBDcmVhdGUgYSBsb2dpY2FsIHJlcGxpY2F0aW9uIHNsb3QuCiAgKgogICogQ3Jl
YXRlUmVwbGljYXRpb25TbG90KCkgaXMgbm90IHVzZWQgYmVjYXVzZSBpdCBkb2VzIG5vdCBw
cm92aWRlIHRoZSBvbmUtcm93CiAgKiByZXN1bHQgc2V0IHRoYXQgY29udGFpbnMgdGhlIExT
Ti4KICAqLwotc3RhdGljIGNoYXIgKgorc3RhdGljIGJvb2wKIGNyZWF0ZV9sb2dpY2FsX3Jl
cGxpY2F0aW9uX3Nsb3QoUEdjb25uICpjb25uLCBzdHJ1Y3QgTG9naWNhbFJlcEluZm8gKmRi
aW5mbykKIHsKIAlQUUV4cEJ1ZmZlciBzdHIgPSBjcmVhdGVQUUV4cEJ1ZmZlcigpOwogCVBH
cmVzdWx0ICAgKnJlcyA9IE5VTEw7CiAJY29uc3QgY2hhciAqc2xvdF9uYW1lID0gZGJpbmZv
LT5yZXBsc2xvdG5hbWU7CiAJY2hhcgkgICAqc2xvdF9uYW1lX2VzYzsKLQljaGFyCSAgICps
c24gPSBOVUxMOwogCiAJQXNzZXJ0KGNvbm4gIT0gTlVMTCk7CiAKQEAgLTEzMDUsNyArMTMz
Niw3IEBAIGNyZWF0ZV9sb2dpY2FsX3JlcGxpY2F0aW9uX3Nsb3QoUEdjb25uICpjb25uLCBz
dHJ1Y3QgTG9naWNhbFJlcEluZm8gKmRiaW5mbykKIAlzbG90X25hbWVfZXNjID0gUFFlc2Nh
cGVMaXRlcmFsKGNvbm4sIHNsb3RfbmFtZSwgc3RybGVuKHNsb3RfbmFtZSkpOwogCiAJYXBw
ZW5kUFFFeHBCdWZmZXIoc3RyLAotCQkJCQkgICJTRUxFQ1QgbHNuIEZST00gcGdfY2F0YWxv
Zy5wZ19jcmVhdGVfbG9naWNhbF9yZXBsaWNhdGlvbl9zbG90KCVzLCAncGdvdXRwdXQnLCBm
YWxzZSwgZmFsc2UsIGZhbHNlKSIsCisJCQkJCSAgIlNFTEVDVCAqIEZST00gcGdfY2F0YWxv
Zy5wZ19jcmVhdGVfbG9naWNhbF9yZXBsaWNhdGlvbl9zbG90KCVzLCAncGdvdXRwdXQnLCBm
YWxzZSwgZmFsc2UsIGZhbHNlKSIsCiAJCQkJCSAgc2xvdF9uYW1lX2VzYyk7CiAKIAlwZ19m
cmVlKHNsb3RfbmFtZV9lc2MpOwpAQCAtMTMyMiwxMCArMTM1Myw5IEBAIGNyZWF0ZV9sb2dp
Y2FsX3JlcGxpY2F0aW9uX3Nsb3QoUEdjb25uICpjb25uLCBzdHJ1Y3QgTG9naWNhbFJlcElu
Zm8gKmRiaW5mbykKIAkJCQkJCSBQUXJlc3VsdEVycm9yTWVzc2FnZShyZXMpKTsKIAkJCVBR
Y2xlYXIocmVzKTsKIAkJCWRlc3Ryb3lQUUV4cEJ1ZmZlcihzdHIpOwotCQkJcmV0dXJuIE5V
TEw7CisJCQlyZXR1cm4gZmFsc2U7CiAJCX0KIAotCQlsc24gPSBwZ19zdHJkdXAoUFFnZXR2
YWx1ZShyZXMsIDAsIDApKTsKIAkJUFFjbGVhcihyZXMpOwogCX0KIApAQCAtMTMzNCw3ICsx
MzY0LDcgQEAgY3JlYXRlX2xvZ2ljYWxfcmVwbGljYXRpb25fc2xvdChQR2Nvbm4gKmNvbm4s
IHN0cnVjdCBMb2dpY2FsUmVwSW5mbyAqZGJpbmZvKQogCiAJZGVzdHJveVBRRXhwQnVmZmVy
KHN0cik7CiAKLQlyZXR1cm4gbHNuOworCXJldHVybiB0cnVlOwogfQogCiBzdGF0aWMgdm9p
ZAotLSAKMi4zMC4yCgo=

--b0b4a1af8735438983cab8c666b66488--