Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wUeVr-001L02-0b for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Jun 2026 05:51:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wUeVp-00HSHc-00 for pgsql-bugs@arkaria.postgresql.org; Wed, 03 Jun 2026 05:51:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wUeVo-00HSHU-0v for pgsql-bugs@lists.postgresql.org; Wed, 03 Jun 2026 05:51:32 +0000 Received: from mail-ua1-x930.google.com ([2607:f8b0:4864:20::930]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wUeVl-00000000rYI-33bN for pgsql-bugs@lists.postgresql.org; Wed, 03 Jun 2026 05:51:30 +0000 Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-961556c15ceso4424958241.3 for ; Tue, 02 Jun 2026 22:51:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780465889; cv=none; d=google.com; s=arc-20240605; b=IHd7RxVRxcQR95388RvkhxzwsqVIPKN5ebnxBlhmoqgXsSEB5UPpvwOZpd2ncHsIaP 2HVQO55iaFdPbVqnUzGJRup5WvFszOCzOCqiNm9uoUUV/rlEZdiU+9iV3INx5Sw1s22b UiDdo+j0ZD7q+GiFcR+v3fH7KMBBUMQlC4ckGWh/4O2+PPTG9dLCRzy4PAi1qcl1QLl1 qHJ4ovLL3N8gzq/Bj+K7e9Hmj5l30w6TR/suqUJRX8X+BrQN1z/fOTSc1CYA/Bmyq9gC /0TQ+a1ZiB6yMCxbEugmHBc6Uf5kivkZLkdJvYzYIY7xXDcbhq40/a4h+8xq9OvhH2FP 5vqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=rCclyd9wUaw5cWEeGmHzZvuz+fzFj9b4MEBq69zzPr8=; fh=/56yBDIz9/os9v2egpBBiIbuaRM/6Trkf0zFYqrKj8c=; b=YOhkt7qnRAjpTVOSKzVnsWjj2UbEpHVy/iql8ggP7FtNDf/EE3CgQBv58R9l9NTSwa kolWgURL9pnzf3R3mrWjM5aLhixHGTTSrj+Q18QP3Sy7f4ozGlsRriar4Z8eiyWjTJg5 EI/GQBBEq693uWtusm6Llcs+vpLjfryI14+lsq6hSaU21OlHGtqwSFvrKpBSWKSAcn1u dgWcILxlK/muE0sZd1vpPJL+eZx56jl1N3ioLwQ51UyVJbrAes1aufQuFN9xrzj12TlB ifsJf/ckxYpxGkrdzLwP+iZL0K2Zp3TYEi+ubi840iomCQWkV93FWWbsdzb6tRqFazST /BRA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780465889; x=1781070689; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rCclyd9wUaw5cWEeGmHzZvuz+fzFj9b4MEBq69zzPr8=; b=pMgr96fJgSCH0uRgHdHkJMDZ01XlM1U3ulm1wIBkpnSPvl3AtpQeMvzNLHNayS+tjX kUkqwstq/ihwzJ1LQIycpJLcK2fpYJkROMBPEZnFXfajEBrwySTwSOtDZvjnQ8/QRAuY SZKkr6kopW3CQmqfyZsU+V8ZH9y95l9yJjbFEjxkTNWz2CLW4eAY21V9dg/8WPhy9UyH 5aElUtqNKEOeMKFeS98Rds7vw28mPvOaRA0cFF3dCqO3miJGivpr/EIILpiFa2Uym22k 1bZ3ql53xJ5Z60y6i+O3crHS60f4gbaln9bLG7JDc4Hz8xj0N6IR80aDRou40ooQlU+9 6Vlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780465889; x=1781070689; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rCclyd9wUaw5cWEeGmHzZvuz+fzFj9b4MEBq69zzPr8=; b=lpAbm0XmojXN967YWlWWhagsLGJiaBVFbouNmd5yleCE5cMP+eh8aDN+l3dWfpKh2n 6RWzIJpubiMAQr2hs2ajPlvC+ZShCktaazk/prco0VoolKSItnMykz4Gtm1upYlhFpk5 3ACjFcUzOHhuhv7ptofPYwpNjw/T8QOJNFi1v4e1vaKNh9EzsCBYuCZoQS9sW01R8nwZ G4XBOddIr2XbQfWFYmPD/FYY8lsm09U5/vet0k54RTath8+1ci5LB9wPKDjO6FJhlPMG gRT1RVbC85srPFIVLPS6V+HcrCNLaCv38Fg4akL6JDky5a0vDSzeQ65v0K8zme6vCcq6 jvRg== X-Forwarded-Encrypted: i=1; AFNElJ85x2y4327JhSG20ohAkffLr/Jl4CbfJP9E27leByDbRcOWnkJoy/LXC8Obm+moh+cJr6OjnAm5/1tB@lists.postgresql.org X-Gm-Message-State: AOJu0YxFJGDRQ+RFZiC8QbFJz0fCuF7vxA5X1RrKbP4fyuLBnotj12Fj elBhTUW4tEGpXN/sRRQaplBy5/tXwTU3GPxdRywQN1PTXZNE5/M6BparriuhXzyYTibm7jvi4ut nrxnc76lPvHnacXFo+Z+1nCncugVOXtg= X-Gm-Gg: Acq92OGuKjaPpHDM6OFRE9AQ2a9xqdOEkJXMeHrfsNDdTr0+6M7KE8KnezER/38JRKZ z0IVt3o/5vijhXt+wcHFmBnpGb4R9EGQ1EQJ8wE8m9OztMh8IYCJqMGdbbBGjgigVvSeU6X46XV PrNvgpWOu/MtmDQ6+dpa9RQUylFtBUuCNcFTiITltP5bC6aHzs0ZaBDZgp8W/oenco5zlTuwlhL uUIdgNJoMnZPSx74oGWNgSpoZhDLf3k5Bu3XP1HUT66c2UhBbcXkZhLwJ5PA0Fc12kDTwgPRPN5 JHefmn/zTbtFK8CYNUarwX/kpitFA7HokMAjydwYhQKzgNv2BsU9zcVMbqx8Z1FDYheUODw+mDn cPL4saIuYObY1fYKiE4YG8U1eQOXZrdber4of X-Received: by 2002:a05:6102:80a4:b0:633:1b2e:e574 with SMTP id ada2fe7eead31-6ec4a310c76mr618876137.29.1780465888590; Tue, 02 Jun 2026 22:51:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Srinath Reddy Sadipiralla Date: Wed, 3 Jun 2026 11:21:17 +0530 X-Gm-Features: AVHnY4L-CYSOGu2fGiMpNKCI41ZCP2AM_RR0l9WA0KhBQ1rpEiRvSzaCE67wESg Message-ID: Subject: Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API To: =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: n.kalinin@postgrespro.ru, pgsql-bugs@lists.postgresql.org, Antonin Houska , b@ida.kurilemu.internal Content-Type: multipart/mixed; boundary="000000000000d31959065353046c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d31959065353046c Content-Type: multipart/alternative; boundary="000000000000d31957065353046a" --000000000000d31957065353046a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=81lvaro, On Mon, Jun 1, 2026 at 10:43=E2=80=AFPM =C3=81lvaro Herrera wrote: > On 2026-May-29, =C3=81lvaro Herrera wrote: > > > On 2026-05-28, PG Bug reporting form wrote: > > > > > It appears that the pgrepack output plugin is accessible through the > > > SQL logical decoding API, even though the plugin code explicitly > > > indicates that this interface is not supported. Reading changes from > > > such a slot can cause a backend process crash in builds with asserts > > > enabled. > > > > Yeah, I would like to have a way to prevent this, if only for > > user-friendliness, but it's not terribly pressing since only a role > > with REPLICATION privs can create the replication slot, which as I > > recall are already pretty powerful. > > How about something like this? It makes your test case throw an error > instead of failing the assertion, which I suppose is an improvement. > > The patch is a bit noisy because I moved more code than the minimum > necessary; but the gist of it is that we allocate RepackDecodingState in > repack_startup(), then have repack_setup_logical_decoding() fill in a > magic number, which we later check in repack_begin_txn(). This is a bit > wasteful, because we have to do that check once for each and every > transaction; however I see no other callback that would let us do this > kind of check after the slot is created but before we start to consume > from it. > The magic guard is correct. One thing worth noting: the check is in the begin callback, which fires only at the transaction's commit, so a single large transaction (a bulk load) is decoded in full and buffered, spilling t= o disk past logical_decoding_work_mem, before the plugin rejects it. That work is then thrown away. It's a misuse path, so this might not be a big concern, I guess, but it does mean the wasted work scales with the transaction size rather than being negligible. Could we reject the pgrepack plugin at slot creation instead, in pg_create_logical_replication_slot() and the CREATE_REPLICATION_SLOT command, so misuse gets a clear "reserved for REPACK (CONCURRENTLY)" error up front, before any decoding? REPACK creates its slot directly via ReplicationSlotCreate(), so it's unaffected, and the begin-callback check with magic guard can stay as the internal safety net. Happy to be told this isn't worth special-casing :) I attached the patch which brings the above behaviour, this patch in on top of your patch. Thoughts? --=20 Thanks, Srinath Reddy Sadipiralla EDB: https://www.enterprisedb.com/ --000000000000d31957065353046a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0=C3=81lvaro,

On Mon, Jun 1, 2026 at 10:43=E2=80=AFPM =C3=81lvaro Herrera <alvherre@kurilemu.de> wrote:
On 2026-May-29, =C3=81= lvaro Herrera wrote:

> On 2026-05-28, PG Bug reporting form wrote:
>
> > It appears that the pgrepack output plugin is accessible through = the
> > SQL logical decoding API, even though the plugin code explicitly<= br> > > indicates that this interface is not supported. Reading changes f= rom
> > such a slot can cause a backend process crash in builds with asse= rts
> > enabled.
>
> Yeah, I would like to have a way to prevent this, if only for
> user-friendliness, but it's not terribly pressing since only a rol= e
> with REPLICATION privs can create the replication slot, which as I
> recall are already pretty powerful.

How about something like this?=C2=A0 It makes your test case throw an error=
instead of failing the assertion, which I suppose is an improvement.

The patch is a bit noisy because I moved more code than the minimum
necessary; but the gist of it is that we allocate RepackDecodingState in repack_startup(), then have repack_setup_logical_decoding() fill in a
magic number, which we later check in repack_begin_txn().=C2=A0 This is a b= it
wasteful, because we have to do that check once for each and every
transaction; however I see no other callback that would let us do this
kind of check after the slot is created but before we start to consume
from it.

The magic guard is correct. One thing wor= th noting: the check is in the
begin callback, which fires only at the t= ransaction's commit, so a single
large transaction (a bulk load) is = decoded in full and buffered, spilling to
disk past logical_decoding_wor= k_mem, before the plugin rejects it.
That work is then thrown away. It&#= 39;s a misuse path, so this might not=C2=A0be
a big concern, I guess, bu= t it does mean the wasted work scales with
the transaction size rather t= han being negligible.

Could we reject the pgrepack plugin at slot cr= eation instead, in
pg_create_logical_replication_slot() and the CREATE_R= EPLICATION_SLOT
command, so misuse gets a clear "reserved for REPAC= K (CONCURRENTLY)"
error up front, before any decoding? REPACK creat= es its slot directly via
ReplicationSlotCreate(), so it's unaffected= , and the begin-callback check
with magic guard can stay as the internal= safety net.
Happy to be told this isn't worth special-casing :)
=
I attached the patch which brings the above behaviour, this patch in on= top of your patch.

Thoughts?=C2=A0


--
Thanks,
Srinath Reddy Sadipiralla
EDB:=C2=A0= https://www.enterprisedb.com/
--000000000000d31957065353046a-- --000000000000d31959065353046c Content-Type: application/octet-stream; name="v1-0002-Reject-the-pgrepack-output-plugin-outside-REPACK-CON.patch" Content-Disposition: attachment; filename="v1-0002-Reject-the-pgrepack-output-plugin-outside-REPACK-CON.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mpxncedm0 RnJvbSA0NTY0MzE4MjM4OTJmZTk4ZGYzZmNmYTMwZDhiOGMwODAwNmQ4OGU2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTcmluYXRoIFJlZGR5IFNhZGlwaXJhbGxhIDxzcmluYXRoMjEz M0BnbWFpbC5jb20+CkRhdGU6IFdlZCwgMyBKdW4gMjAyNiAxMDoyOTozMCArMDUzMApTdWJqZWN0 OiBbUEFUQ0hdIFJlamVjdCB0aGUgInBncmVwYWNrIiBvdXRwdXQgcGx1Z2luIG91dHNpZGUgUkVQ QUNLCiAoQ09OQ1VSUkVOVExZKQoKVGhlICJwZ3JlcGFjayIgb3V0cHV0IHBsdWdpbiBpcyBhbiBp bnRlcm5hbCBjb21wb25lbnQgb2YgUkVQQUNLCihDT05DVVJSRU5UTFkpIGFuZCBpcyBub3QgbWVh bnQgdG8gYmUgZHJpdmVuIHRocm91Z2ggdGhlIGdlbmVyaWMgbG9naWNhbApkZWNvZGluZyBpbnRl cmZhY2UuCgotLS0KIGNvbnRyaWIvdGVzdF9kZWNvZGluZy9leHBlY3RlZC9yZXBhY2sub3V0IHwg IDUgKysrKysKIGNvbnRyaWIvdGVzdF9kZWNvZGluZy9zcWwvcmVwYWNrLnNxbCAgICAgIHwgIDQg KysrKwogc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vc2xvdGZ1bmNzLmMgICAgICAgfCAxNCArKysr KysrKysrKysrKwogc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vd2Fsc2VuZGVyLmMgICAgICAgfCAx MCArKysrKysrKysrCiA0IGZpbGVzIGNoYW5nZWQsIDMzIGluc2VydGlvbnMoKykKCmRpZmYgLS1n aXQgYS9jb250cmliL3Rlc3RfZGVjb2RpbmcvZXhwZWN0ZWQvcmVwYWNrLm91dCBiL2NvbnRyaWIv dGVzdF9kZWNvZGluZy9leHBlY3RlZC9yZXBhY2sub3V0CmluZGV4IDYyMDRlNjIwYjQzLi4yNzMy NTYxMjgxYiAxMDA2NDQKLS0tIGEvY29udHJpYi90ZXN0X2RlY29kaW5nL2V4cGVjdGVkL3JlcGFj ay5vdXQKKysrIGIvY29udHJpYi90ZXN0X2RlY29kaW5nL2V4cGVjdGVkL3JlcGFjay5vdXQKQEAg LTk5LDUgKzk5LDEwIEBAIFJFUEFDSyAoQ09OQ1VSUkVOVExZKSByZXBhY2tfY29uY19yZXBsaWRl bnQ7CiBFUlJPUjogIGNhbm5vdCBleGVjdXRlIFJFUEFDSyAoQ09OQ1VSUkVOVExZKSBvbiByZWxh dGlvbiAicmVwYWNrX2NvbmNfcmVwbGlkZW50IgogREVUQUlMOiAgUkVQQUNLIChDT05DVVJSRU5U TFkpIGRvZXMgbm90IHN1cHBvcnQgZGVmZXJyYWJsZSBwcmltYXJ5IGtleXMuCiBISU5UOiAgVXNl IEFMVEVSIFRBQkxFIC4uLiBSRVBMSUNBIElERU5USVRZIFVTSU5HIElOREVYIHRvIGRlc2lnbmF0 ZSBhbm90aGVyIGluZGV4IGFzIHJlcGxpY2EgaWRlbnRpdHkuCistLSBUaGUgInBncmVwYWNrIiBv dXRwdXQgcGx1Z2luIGlzIGludGVybmFsIHRvIFJFUEFDSyAoQ09OQ1VSUkVOVExZKTsgaXQgY2Fu bm90CistLSBiZSBzZWxlY3RlZCB0aHJvdWdoIHRoZSBnZW5lcmljIGxvZ2ljYWwgZGVjb2Rpbmcg aW50ZXJmYWNlIChidWcgIzE5NTAwKS4KK1NFTEVDVCBwZ19jcmVhdGVfbG9naWNhbF9yZXBsaWNh dGlvbl9zbG90KCdyZXBhY2tfbWlzdXNlX3Nsb3QnLCAncGdyZXBhY2snKTsKK0VSUk9SOiAgb3V0 cHV0IHBsdWdpbiAicGdyZXBhY2siIGNhbm5vdCBiZSB1c2VkIHRocm91Z2ggdGhlIGxvZ2ljYWwg ZGVjb2RpbmcgaW50ZXJmYWNlCitERVRBSUw6ICBUaGlzIG91dHB1dCBwbHVnaW4gaXMgcmVzZXJ2 ZWQgZm9yIGludGVybmFsIHVzZSBieSBSRVBBQ0sgKENPTkNVUlJFTlRMWSkuCiAtLSBjbGVhbiB1 cAogRFJPUCBUQUJMRSByZXBhY2tfY29uY19yZXBsaWRlbnQsIGNsc3RycGFydDsKZGlmZiAtLWdp dCBhL2NvbnRyaWIvdGVzdF9kZWNvZGluZy9zcWwvcmVwYWNrLnNxbCBiL2NvbnRyaWIvdGVzdF9k ZWNvZGluZy9zcWwvcmVwYWNrLnNxbAppbmRleCBjZWEzYmQzMzY4OS4uYTdjYjYxNWU1NWQgMTAw NjQ0Ci0tLSBhL2NvbnRyaWIvdGVzdF9kZWNvZGluZy9zcWwvcmVwYWNrLnNxbAorKysgYi9jb250 cmliL3Rlc3RfZGVjb2Rpbmcvc3FsL3JlcGFjay5zcWwKQEAgLTczLDUgKzczLDkgQEAgUkVQQUNL IChDT05DVVJSRU5UTFkpIHJlcGFja19jb25jX3JlcGxpZGVudDsKIEFMVEVSIFRBQkxFIHJlcGFj a19jb25jX3JlcGxpZGVudCBBREQgUFJJTUFSWSBLRVkgKGkpIERFRkVSUkFCTEU7CiBSRVBBQ0sg KENPTkNVUlJFTlRMWSkgcmVwYWNrX2NvbmNfcmVwbGlkZW50OwogCistLSBUaGUgInBncmVwYWNr IiBvdXRwdXQgcGx1Z2luIGlzIGludGVybmFsIHRvIFJFUEFDSyAoQ09OQ1VSUkVOVExZKTsgaXQg Y2Fubm90CistLSBiZSBzZWxlY3RlZCB0aHJvdWdoIHRoZSBnZW5lcmljIGxvZ2ljYWwgZGVjb2Rp bmcgaW50ZXJmYWNlIChidWcgIzE5NTAwKS4KK1NFTEVDVCBwZ19jcmVhdGVfbG9naWNhbF9yZXBs aWNhdGlvbl9zbG90KCdyZXBhY2tfbWlzdXNlX3Nsb3QnLCAncGdyZXBhY2snKTsKKwogLS0gY2xl YW4gdXAKIERST1AgVEFCTEUgcmVwYWNrX2NvbmNfcmVwbGlkZW50LCBjbHN0cnBhcnQ7CmRpZmYg LS1naXQgYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9zbG90ZnVuY3MuYyBiL3NyYy9iYWNrZW5k L3JlcGxpY2F0aW9uL3Nsb3RmdW5jcy5jCmluZGV4IDE2ZmJkMzgzNzM1Li4xNzU0OGFiZjYwMSAx MDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vc2xvdGZ1bmNzLmMKKysrIGIvc3Jj L2JhY2tlbmQvcmVwbGljYXRpb24vc2xvdGZ1bmNzLmMKQEAgLTEzNiw2ICsxMzYsMjAgQEAgY3Jl YXRlX2xvZ2ljYWxfcmVwbGljYXRpb25fc2xvdChjaGFyICpuYW1lLCBjaGFyICpwbHVnaW4sCiAK IAlBc3NlcnQoIU15UmVwbGljYXRpb25TbG90KTsKIAorCS8qCisJICogVGhlICJwZ3JlcGFjayIg b3V0cHV0IHBsdWdpbiBpcyBmb3IgaW50ZXJuYWwgdXNlIGJ5IFJFUEFDSworCSAqIChDT05DVVJS RU5UTFkpIG9ubHkuICBSZWplY3QgaXQgaGVyZSBzbyB0aGF0IG1pc3VzZSB0aHJvdWdoIHRoZSBT UUwKKwkgKiBpbnRlcmZhY2UgZmFpbHMgaW1tZWRpYXRlbHkgd2l0aCBhIGNsZWFyIG1lc3NhZ2Us IGluc3RlYWQgb2YgYmVpbmcKKwkgKiBjYXVnaHQgbGF0ZXIgKGFuZCBvbmx5IGFmdGVyIHNvbWUg ZGVjb2Rpbmcgd29yaykgYnkgdGhlIHBsdWdpbidzIG93bgorCSAqIG1hZ2ljLW51bWJlciBjaGVj ayBpbiBpdHMgYmVnaW4gY2FsbGJhY2suICBSRVBBQ0sgY3JlYXRlcyBpdHMgc2xvdAorCSAqIGRp cmVjdGx5IHZpYSBSZXBsaWNhdGlvblNsb3RDcmVhdGUoKSwgc28gaXQgaXMgdW5hZmZlY3RlZC4K KwkgKi8KKwlpZiAoc3RyY21wKHBsdWdpbiwgInBncmVwYWNrIikgPT0gMCkKKwkJZXJlcG9ydChF UlJPUiwKKwkJCQllcnJjb2RlKEVSUkNPREVfRkVBVFVSRV9OT1RfU1VQUE9SVEVEKSwKKwkJCQll cnJtc2coIm91dHB1dCBwbHVnaW4gXCJwZ3JlcGFja1wiIGNhbm5vdCBiZSB1c2VkIHRocm91Z2gg dGhlIGxvZ2ljYWwgZGVjb2RpbmcgaW50ZXJmYWNlIiksCisJCQkJZXJyZGV0YWlsKCJUaGlzIG91 dHB1dCBwbHVnaW4gaXMgcmVzZXJ2ZWQgZm9yIGludGVybmFsIHVzZSBieSBSRVBBQ0sgKENPTkNV UlJFTlRMWSkuIikpOworCiAJLyoKIAkgKiBBY3F1aXJlIGEgbG9naWNhbCBkZWNvZGluZyBzbG90 LCB0aGlzIHdpbGwgY2hlY2sgZm9yIGNvbmZsaWN0aW5nIG5hbWVzLgogCSAqIEluaXRpYWxseSBj cmVhdGUgcGVyc2lzdGVudCBzbG90IGFzIGVwaGVtZXJhbCAtIHRoYXQgYWxsb3dzIHVzIHRvCmRp ZmYgLS1naXQgYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi93YWxzZW5kZXIuYyBiL3NyYy9iYWNr ZW5kL3JlcGxpY2F0aW9uL3dhbHNlbmRlci5jCmluZGV4IDA0YWE3NzBkOTgxLi5iOWU1MmEyMDE3 MyAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcmVwbGljYXRpb24vd2Fsc2VuZGVyLmMKKysrIGIv c3JjL2JhY2tlbmQvcmVwbGljYXRpb24vd2Fsc2VuZGVyLmMKQEAgLTEyNzAsNiArMTI3MCwxNiBA QCBDcmVhdGVSZXBsaWNhdGlvblNsb3QoQ3JlYXRlUmVwbGljYXRpb25TbG90Q21kICpjbWQpCiAK IAkJQ2hlY2tMb2dpY2FsRGVjb2RpbmdSZXF1aXJlbWVudHMoZmFsc2UpOwogCisJCS8qCisJCSAq IFRoZSAicGdyZXBhY2siIG91dHB1dCBwbHVnaW4gaXMgcmVzZXJ2ZWQgZm9yIFJFUEFDSyAoQ09O Q1VSUkVOVExZKTsKKwkJICogcmVqZWN0IGl0IGhlcmUgdG9vIChzZWUgY3JlYXRlX2xvZ2ljYWxf cmVwbGljYXRpb25fc2xvdCgpKS4KKwkJICovCisJCWlmIChzdHJjbXAoY21kLT5wbHVnaW4sICJw Z3JlcGFjayIpID09IDApCisJCQllcmVwb3J0KEVSUk9SLAorCQkJCQllcnJjb2RlKEVSUkNPREVf RkVBVFVSRV9OT1RfU1VQUE9SVEVEKSwKKwkJCQkJZXJybXNnKCJvdXRwdXQgcGx1Z2luIFwicGdy ZXBhY2tcIiBjYW5ub3QgYmUgdXNlZCB0aHJvdWdoIHRoZSBsb2dpY2FsIGRlY29kaW5nIGludGVy ZmFjZSIpLAorCQkJCQllcnJkZXRhaWwoIlRoaXMgb3V0cHV0IHBsdWdpbiBpcyByZXNlcnZlZCBm b3IgaW50ZXJuYWwgdXNlIGJ5IFJFUEFDSyAoQ09OQ1VSUkVOVExZKS4iKSk7CisKIAkJLyoKIAkJ ICogSW5pdGlhbGx5IGNyZWF0ZSBwZXJzaXN0ZW50IHNsb3QgYXMgZXBoZW1lcmFsIC0gdGhhdCBh bGxvd3MgdXMgdG8KIAkJICogbmljZWx5IGhhbmRsZSBlcnJvcnMgZHVyaW5nIGluaXRpYWxpemF0 aW9uIGJlY2F1c2UgaXQnbGwgZ2V0Ci0tIAoyLjQzLjAKCg== --000000000000d31959065353046c--