MIME-Version: 1.0
References: <6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com>
 <165530.1752362320@sss.pgh.pa.us>
 <02a7cd37-e2fc-4212-8b19-f8c239c95fb8@app.fastmail.com>
 <e396ecf3-4227-4918-b9ff-e9568dcebcf0@app.fastmail.com>
 <b6a427fe-2ed6-4568-85d9-207a68172617@app.fastmail.com>
 <CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
 <96f00bf1-cc9d-4520-9d02-9e14e7767c88@app.fastmail.com>
 <30c2aa7d-dd6c-4b68-a2e4-f217a1a34acf@app.fastmail.com>
 <CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
 <0b4d402a-9ac2-4aa8-acf8-8231dbe579ea@app.fastmail.com>
 <c8e84bb2-d2e5-4a77-b547-3a93c5778e7e@app.fastmail.com>
 <3095599.1758644879@sss.pgh.pa.us>
 <0dc6a2cc-5216-4dc1-9dd2-430cafc6095b@app.fastmail.com>
 <E7D8A5CD-C445-4713-B6B7-6CC1D3A71161@gmail.com>
 <baf71275-9083-41be-ae13-f80821541a1a@app.fastmail.com>
 <52CC167F-763B-4ECA-B0B4-DAB381816828@gmail.com>
 <d35a114d-204a-4b40-9284-06749532b724@app.fastmail.com>
 <9186C6D0-F7A9-482A-9183-89E530B57E36@gmail.com>
 <da0996!!!!!!d8-ecf9-490d-bbd0-2a5bdb5b115a@app.fastmail.com>
 <D1CF7CA5-213A-4FC1-86DB-052D58904A0A@gmail.com>
 <cad78ff4-aae9-4c1c-8e16-ff0ccd4957f1@app.fastmail.com>
 <1073593.1759423179@sss.pgh.pa.us>
 <4bd5e6c4-6fa7-44bb-869d-59a32a331fa8@app.fastmail.com>
 <CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
 <85828f29-e72e-4400-94f3-9a69bc8dc239@app.fastmail.com>
 <2495353.1759860890@sss.pgh.pa.us>
 <8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com>
 <2531672.1759868124@sss.pgh.pa.us>
 <474efa78-337c-41cd-a73a-f845a0115109@app.fastmail.com>
 <2749343.1759949176@sss.pgh.pa.us>
 <8bfca2be-1ec0-4e15-aafb-0b7b661fe936@app.fastmail.com>
 <9eba307f-f2fb-48f0-9507-2e197f39ef9e@app.fastmail.com>
 <cde2a91d-d47a-43b5-ab27-f98aa739d38e@app.fastmail.com>
 <8c71183a-0d28-4bcf-a806-78446ff95404@app.fastmail.com>
 <1009807.1760476747@sss.pgh.pa.us>
 <1F7227F5-C33D-4E2C-8511-33F1468590D0@gmail.com>
 <0a5a20d3-4621-46b3-b2ab-903f63a20dea@app.fastmail.com>
 <6F913129-ABEF-4004-AAF3-F22FC34!29AE8@gmail.com>
 <cbabbb45-ec27-47f1-a8f3-eb29073e9aef@app.fastmail.com>
 <ceab2c54-3463-4029-a7d8-895a617bb457@app.fastmail.com>
 <1547585.1760645808@sss.pgh.pa.us>
 <b8df8040-1b15-4a1a-b5f6-74acebbd2d0c@app.fastmail.com>
In-Reply-To: <b8df8040-1b15-4a1a-b5f6-74acebbd2d0c@app.fastmail.com>
From: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
Date: Mon, 20 Oct 2025 19:43:27 +0300
Message-ID: 
 <CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
Subject: Re: Optimize LISTEN/NOTIFY
To: Joel Jacobson <joel@compiler.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Chao Li <li.evan.chao@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="0000000000000317f3064199c969"
Archived-At: 
 <https://www.postgresql.org/message-id/CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh%2B9CheXprm5vRVMQ%40mail.gmail.com>
Precedence: bulk

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

On Mon, Oct 20, 2025 at 1:07=E2=80=AFAM Joel Jacobson <joel@compiler.org> w=
rote:
>
> > Minute of brainstorming
> >
> > I also thought about a workload that probably frequently can be met.
> > Let's say we have sequence of notifications:
> >
> > F F F T F F F T F F F T
> >
> > Here F - notification from the channel we don't care about and T - the =
opposite.
> > It seems that after the first 'T' notification it will be more
> > difficult for notifying backends to do 'direct advancement' as there
> > will be some lag before the listener reads the notification and
> > advances its position. Not sure if it's a problem, probably it depends
> > on the intensity of notifications.
>
> Hmm, I realize both the advisoryPos and donePos ideas share a problem;
> they both require listening backends to wakeup eventually anyway,
> just to advance the 'pos'.
>
> The holy grail would be to avoid this context switching cost entirely,
> and only need to wakeup listening backends when they are actually
> interested in the queued notifications. I think the third idea,
> alt3, is most promising in achieving this goal.
>

Yeah, it would be great.

> > But maybe we can use a bit more
> > sophisticated data structure here? Something like a list of skip
> > ranges. Every entry in the list is the range (pos1, pos2) that the
> > listener can skip during the reading. So instead of advancing
> > advisoryPos every notifying backend should add skip range to the list.
> > Notifying backends can merge neighbour ranges (pos1, pos2) & (pos2,
> > pos3) -> (pos1, pos3). We also can limit the number of entries to 5
> > for example. Listeners on their side should clear the list before
> > reading and skip all ranges from it. What do you think? Is it
> > overkill?
>
> Hmm, maybe, but I'm a bit wary about too much complication.
> Hopefully there is a simpler solution that avoids the need for this,
> but sure, if we can't find one, then I'm positive to try this skip ranges=
 idea.
>

Yes, and it's probably worth doing a benchmarking to see if it's a
problem at all before implementing anything.

> >> > A different line of thought could be to get rid of
> >> > asyncQueueReadAllNotifications's optimization of moving the
> >> > queue pos only once, per
> >> >
> >> >        * (We could alternatively retake NotifyQueueLock and move the=
 position
> >> >        * before handling each individual message, but that seems lik=
e too much
> >> >        * lock traffic.)
> >> >
> >> > Since we only need shared lock to advance our own queue pos,
> >> > maybe that wouldn't be too awful.  Not sure.
> >>
> >> Above idea is implemented in 0002-optimize_listen_notify-v19-alt3.txt
> >>
> >
> > Hmm, it seems we still have the race when in the beginning of
> > asyncQueueReadAllNotifications we read pos into the local variable and
> > release the lock. IIUC to avoid the race without introducing another
> > field here, the listener needs to hold the lock until it updates its
> > position so that the notifying backend cannot change it concurrently.
>
> *** 0002-optimize_listen_notify-v20-alt3.txt:
>
> * Fixed; the shared 'pos' is now only updated if the new position is ahea=
d.
>

I managed to reproduce the race with v20-alt3. I tried to write a TAP
test reproducing the issue, so it was easier to validate changes.
Please find the attached TAP test. I added it to some random package
for simplicity.


Best regards,
Arseniy Mukhin

--0000000000000317f3064199c969
Content-Type: application/octet-stream;
	name="0001-TAP-test-with-listener-pos-race.patch.nocfbot"
Content-Disposition: attachment;
	filename="0001-TAP-test-with-listener-pos-race.patch.nocfbot"
Content-Transfer-Encoding: base64
Content-ID: <f_mgzd6ofw0>
X-Attachment-Id: f_mgzd6ofw0

RnJvbSA4MDViNTNjY2NkNWE5MGU3ODc0NDc0OTU3NTNiNGRiOWVkMWVjNzY1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBcnNlbml5IE11a2hpbiA8YXJzZW5peS5tdWtoaW4uZGV2QGdt
YWlsLmNvbT4KRGF0ZTogTW9uLCAyMCBPY3QgMjAyNSAxNToxNDozNiArMDMwMApTdWJqZWN0OiBb
UEFUQ0hdIFRBUCB0ZXN0IHdpdGggbGlzdGVuZXIgcG9zIHJhY2UKCi0tLQogc3JjL2JhY2tlbmQv
Y29tbWFuZHMvYXN5bmMuYyAgICAgICAgICAgICAgICAgIHwgIDUgKwogc3JjL3Rlc3QvYXV0aGVu
dGljYXRpb24vbWVzb24uYnVpbGQgICAgICAgICAgIHwgIDEgKwogLi4uL2F1dGhlbnRpY2F0aW9u
L3QvMDA4X2xpc3Rlbi1wb3MtcmFjZS5wbCAgIHwgOTEgKysrKysrKysrKysrKysrKysrKwogMyBm
aWxlcyBjaGFuZ2VkLCA5NyBpbnNlcnRpb25zKCspCiBjcmVhdGUgbW9kZSAxMDA2NDQgc3JjL3Rl
c3QvYXV0aGVudGljYXRpb24vdC8wMDhfbGlzdGVuLXBvcy1yYWNlLnBsCgpkaWZmIC0tZ2l0IGEv
c3JjL2JhY2tlbmQvY29tbWFuZHMvYXN5bmMuYyBiL3NyYy9iYWNrZW5kL2NvbW1hbmRzL2FzeW5j
LmMKaW5kZXggNGU2NTU2ZmI4ZDEuLmU0ZTY1YjAyZTk4IDEwMDY0NAotLS0gYS9zcmMvYmFja2Vu
ZC9jb21tYW5kcy9hc3luYy5jCisrKyBiL3NyYy9iYWNrZW5kL2NvbW1hbmRzL2FzeW5jLmMKQEAg
LTE2Nyw2ICsxNjcsNyBAQAogI2luY2x1ZGUgInV0aWxzL3BzX3N0YXR1cy5oIgogI2luY2x1ZGUg
InV0aWxzL3NuYXBtZ3IuaCIKICNpbmNsdWRlICJ1dGlscy90aW1lc3RhbXAuaCIKKyNpbmNsdWRl
ICJ1dGlscy9pbmplY3Rpb25fcG9pbnQuaCIKIAogCiAvKgpAQCAtMTk1NCw2ICsxOTU1LDggQEAg
U2lnbmFsQmFja2VuZHModm9pZCkKIAlpbnQJCQljb3VudDsKIAlMaXN0Q2VsbCAgICpsYzsKIAor
CUlOSkVDVElPTl9QT0lOVCgibGlzdGVuLW5vdGlmeS1zaWduYWwtYmFja2VuZHMiLCBOVUxMKTsK
KwogCS8qCiAJICogQXR0YWNoIHRvIHRoZSBjaGFubmVsIGhhc2ggaWYgbmVlZGVkLiAgV2UgbWln
aHQgbm90IGhhdmUgb25lIGlmIHRoaXMKIAkgKiBiYWNrZW5kIGhhc24ndCBkb25lIExJU1RFTiwg
YnV0IHdlIG5lZWQgaXQgdG8gZmluZCBsaXN0ZW5lcnMuCkBAIC0yMzIxLDYgKzIzMjQsOCBAQCBh
c3luY1F1ZXVlUmVhZEFsbE5vdGlmaWNhdGlvbnModm9pZCkKIAloZWFkID0gUVVFVUVfSEVBRDsK
IAlMV0xvY2tSZWxlYXNlKE5vdGlmeVF1ZXVlTG9jayk7CiAKKwlJTkpFQ1RJT05fUE9JTlQoImxp
c3Rlbi1ub3RpZnktbG9jYWwtcG9zIiwgTlVMTCk7CisKIAlpZiAoUVVFVUVfUE9TX0VRVUFMKHBv
cywgaGVhZCkpCiAJewogCQkvKiBOb3RoaW5nIHRvIGRvLCB3ZSBoYXZlIHJlYWQgYWxsIG5vdGlm
aWNhdGlvbnMgYWxyZWFkeS4gKi8KZGlmZiAtLWdpdCBhL3NyYy90ZXN0L2F1dGhlbnRpY2F0aW9u
L21lc29uLmJ1aWxkIGIvc3JjL3Rlc3QvYXV0aGVudGljYXRpb24vbWVzb24uYnVpbGQKaW5kZXgg
ODAwYjNhNWZmNDAuLmMzM2YwMDY1YjFkIDEwMDY0NAotLS0gYS9zcmMvdGVzdC9hdXRoZW50aWNh
dGlvbi9tZXNvbi5idWlsZAorKysgYi9zcmMvdGVzdC9hdXRoZW50aWNhdGlvbi9tZXNvbi5idWls
ZApAQCAtMTYsNiArMTYsNyBAQCB0ZXN0cyArPSB7CiAgICAgICAndC8wMDVfc3NwaS5wbCcsCiAg
ICAgICAndC8wMDZfbG9naW5fdHJpZ2dlci5wbCcsCiAgICAgICAndC8wMDdfcHJlX2F1dGgucGwn
LAorICAgICAgJ3QvMDA4X2xpc3Rlbi1wb3MtcmFjZS5wbCcsCiAgICAgXSwKICAgfSwKIH0KZGlm
ZiAtLWdpdCBhL3NyYy90ZXN0L2F1dGhlbnRpY2F0aW9uL3QvMDA4X2xpc3Rlbi1wb3MtcmFjZS5w
bCBiL3NyYy90ZXN0L2F1dGhlbnRpY2F0aW9uL3QvMDA4X2xpc3Rlbi1wb3MtcmFjZS5wbApuZXcg
ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMC4uMDk5NDQ0MDdlNGYKLS0tIC9kZXYv
bnVsbAorKysgYi9zcmMvdGVzdC9hdXRoZW50aWNhdGlvbi90LzAwOF9saXN0ZW4tcG9zLXJhY2Uu
cGwKQEAgLTAsMCArMSw5MSBAQAorIyBDb3B5cmlnaHQgKGMpIDIwMjEtMjAyNSwgUG9zdGdyZVNR
TCBHbG9iYWwgRGV2ZWxvcG1lbnQgR3JvdXAKKwordXNlIHN0cmljdDsKK3VzZSB3YXJuaW5ncyBG
QVRBTCA9PiAnYWxsJzsKKwordXNlIFBvc3RncmVTUUw6OlRlc3Q6OkNsdXN0ZXI7Cit1c2UgUG9z
dGdyZVNRTDo6VGVzdDo6VXRpbHM7Cit1c2UgVGltZTo6SGlSZXMgcXcodXNsZWVwKTsKK3VzZSBU
ZXN0OjpNb3JlOworCitpZiAoJEVOVntlbmFibGVfaW5qZWN0aW9uX3BvaW50c30gbmUgJ3llcycp
IHsKKyAgICBwbGFuIHNraXBfYWxsID0+ICdJbmplY3Rpb24gcG9pbnRzIG5vdCBzdXBwb3J0ZWQg
YnkgdGhpcyBidWlsZCc7Cit9CisKK215ICRub2RlID0gUG9zdGdyZVNRTDo6VGVzdDo6Q2x1c3Rl
ci0+bmV3KCJ0ZXN0Iik7Ciskbm9kZS0+aW5pdDsKKyRub2RlLT5zdGFydDsKKworCitpZiAoISRu
b2RlLT5jaGVja19leHRlbnNpb24oJ2luamVjdGlvbl9wb2ludHMnKSkgeworICAgIHBsYW4gc2tp
cF9hbGwgPT4gJ0V4dGVuc2lvbiBpbmplY3Rpb25fcG9pbnRzIG5vdCBpbnN0YWxsZWQnOworfQor
Ciskbm9kZS0+c2FmZV9wc3FsKCdwb3N0Z3JlcycsICdDUkVBVEUgRVhURU5TSU9OIGluamVjdGlv
bl9wb2ludHMnKTsKKworbXkgJGxpc3RlbmVyID0gJG5vZGUtPmJhY2tncm91bmRfcHNxbCgncG9z
dGdyZXMnKTsKK215ICRsaXN0ZW5lcl93aXRoX2ludmFsaWRfcG9zID0gJG5vZGUtPmJhY2tncm91
bmRfcHNxbCgncG9zdGdyZXMnKTsKK215ICRub3RpZnlpbmdfcHNxbCA9ICRub2RlLT5iYWNrZ3Jv
dW5kX3BzcWwoJ3Bvc3RncmVzJyk7CisKKyMgc2V0dXAgaW5qZWN0aW9uIHBvaW50cworJG5vZGUt
PnNhZmVfcHNxbCgncG9zdGdyZXMnLCAiU0VMRUNUIGluamVjdGlvbl9wb2ludHNfYXR0YWNoKCds
aXN0ZW4tbm90aWZ5LXNpZ25hbC1iYWNrZW5kcycsICd3YWl0Jyk7Iik7CisKKyRsaXN0ZW5lcl93
aXRoX2ludmFsaWRfcG9zLT5xdWVyeV9zYWZlKAorICAgIHFxWworICAgICBTRUxFQ1QgaW5qZWN0
aW9uX3BvaW50c19zZXRfbG9jYWwoKTsKKyAgICAgU0VMRUNUIGluamVjdGlvbl9wb2ludHNfYXR0
YWNoKCdsaXN0ZW4tbm90aWZ5LWxvY2FsLXBvcycsICd3YWl0Jyk7CisgXSk7CisKKyMgbGlzdGVu
ZXIgc3RhcnRzIGxpc3RlbmluZyB0byBjaGFubmVsIGNoLCBhbmQgc3RhcnRzIGEgdHJhbnNhY3Rp
b24sCisjIHdoaWxlIGxpc3RlbmVyIGlzIHdpdGhpbiBhbiBhY3RpdmUgdHJhbnNhY3Rpb24sIGl0
cyBwb3Mgd2lsbCBiZSAwLAorIyBhbmQgdGhlcmVmb3JlIGFsbCBuZXcgbGlzdGVuZXJzIHdpbGwg
aGF2ZSB0byBzdGFydCByZWFkaW5nIGZyb20gMCBwb3NpdGlvbiB0b28gYmVjYXVzZSBvZiBpdC4K
KyRsaXN0ZW5lci0+cXVlcnlfc2FmZSgiTElTVEVOIGNoOyIpOworJGxpc3RlbmVyLT5xdWVyeV9z
YWZlKCJCRUdJTjsiKTsKKworIyBjcmVhdGUgYSBsb3Qgb2Ygbm90aWZpY2F0aW9ucyBhbmQgc3Rh
cnQgd2FpdGluZworIyBvbiBsaXN0ZW4tbm90aWZ5LXNpZ25hbC1iYWNrZW5kcyAoYmVmb3JlIGRp
cmVjdCBhZHZhbmNlbWVudCkKKyRub3RpZnlpbmdfcHNxbC0+cXVlcnlfdW50aWwoCisgICAgcXIv
c3RhcnQvLCBxKAorICAgXGVjaG8gc3RhcnQKKyAgIEJFR0lOOworICAgc2VsZWN0IHBnX25vdGlm
eSgnY2gnLCByZXBlYXQoJ2EnLDMwMDApIHx8IHg6OnRleHQpIGZyb20gZ2VuZXJhdGVfc2VyaWVz
KDEsMTAwKSBhcyB4OworICAgQ09NTUlUOworCispKTsKKyMgV2FpdCB1bnRpbCBub3RpZnlpbmdf
cHNxbCBlbnRlcnMgdGhlIHdhaXQgaW5qZWN0aW9uIHBvaW50LgorJG5vZGUtPndhaXRfZm9yX2V2
ZW50KCdjbGllbnQgYmFja2VuZCcsCSdsaXN0ZW4tbm90aWZ5LXNpZ25hbC1iYWNrZW5kcycpOwor
CisjIGxpc3RlbmVyX3dpdGhfaW52YWxpZF9wb3MgZXhlY3V0ZXMgTElTVEVOIGNvbW1hbmQgYW5k
IHN0YXJ0cworIyB3YWl0aW5nIG9uIHRoZSBpbmplY3Rpb24gcG9pbnQgd2l0aCBwb3MgPSAwIGlu
IGxvY2FsIHZhcmlhYmxlCiskbGlzdGVuZXJfd2l0aF9pbnZhbGlkX3Bvcy0+cXVlcnlfdW50aWwo
CisgICAgcXIvc3RhcnQvLCBxKAorICAgXGVjaG8gc3RhcnQKKyAgIExJU1RFTiBjaDI7CispKTsK
KyMgV2FpdCB1bnRpbCBsaXN0ZW5lcl93aXRoX2ludmFsaWRfcG9zIGVudGVycyB0aGUgd2FpdCBp
bmplY3Rpb24gcG9pbnQuCiskbm9kZS0+d2FpdF9mb3JfZXZlbnQoJ2NsaWVudCBiYWNrZW5kJywJ
J2xpc3Rlbi1ub3RpZnktbG9jYWwtcG9zJyk7CisKKyMgd2FrZSB1cCBub3RpZnlpbmcgYmFja2Vu
ZC4gZGlyZWN0IGFkdmFuY2VtZW50IHNob3VsZCBiZSBhcHBsaWVkIG5vdyB0byBsaXN0ZW5lcl93
aXRoX2ludmFsaWRfcG9zCisjIGxpc3RlbmVyX3dpdGhfaW52YWxpZF9wb3MgaXMgc3RpbGwgd2Fp
dGluZyBvbiBpbmplY3Rpb24gcG9pbnQgd2l0aCBsb2NhbCBwb3MgPSAwCiskbm9kZS0+c2FmZV9w
c3FsKCdwb3N0Z3JlcycsICJTRUxFQ1QgaW5qZWN0aW9uX3BvaW50c193YWtldXAoJ2xpc3Rlbi1u
b3RpZnktc2lnbmFsLWJhY2tlbmRzJyk7Iik7CisKKyNzbGVlcCBqdXN0IHRvIGJlIHN1cmUgdGhh
dCBkaXJlY3QgYWR2YW5jZW1lbnQgd2FzIGFwcGxpZWQgdG8gbGlzdGVuZXJfd2l0aF9pbnZhbGlk
X3Bvcworc2xlZXAgMTsKKworIyBsZXQgbGlzdGVuZXIgdG8gYWR2YW5jZSBpdHMgcG9zaXRpb24g
dG8gdW5ibG9jayBxdWV1ZSB0cnVuY2F0aW5nCiskbGlzdGVuZXItPnF1ZXJ5X3NhZmUoIkNPTU1J
VCIpOworCisjIHRydW5jYXRlIHRoZSBxdWV1ZQorJG5vZGUtPnNhZmVfcHNxbCgncG9zdGdyZXMn
LCAic2VsZWN0IHBnX25vdGlmaWNhdGlvbl9xdWV1ZV91c2FnZSgpOyIpOworCisKKyMgd2FrZSB1
cCBsaXN0ZW5lcl93aXRoX2ludmFsaWRfcG9zIHdpdGggbG9jYWwgY29weSBvZiBwb3MgPSAwLiBx
dWV1ZSBoYXMgYmVlbiB0cnVuY2F0ZWQgYWxyZWFkeS4KKyMgdGVzdCBzaG91bGQgZmFpbCBhZnRl
ciBpdC4gMDA4X2xpc3Rlbi1wb3MtcmFjZV90ZXN0LmxvZyBjb250YWlucyBlcnJvciBkZXRhaWxz
Ciskbm9kZS0+c2FmZV9wc3FsKCdwb3N0Z3JlcycsIlNFTEVDVCBpbmplY3Rpb25fcG9pbnRzX3dh
a2V1cCgnbGlzdGVuLW5vdGlmeS1sb2NhbC1wb3MnKTsiKTsKKworCiskbGlzdGVuZXItPnF1aXQo
KTsKKyRsaXN0ZW5lcl93aXRoX2ludmFsaWRfcG9zLT5xdWl0KCk7Ciskbm90aWZ5aW5nX3BzcWwt
PnF1aXQoKTsKKworZG9uZV90ZXN0aW5nKCk7Ci0tIAoyLjQzLjAKCg==
--0000000000000317f3064199c969--