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 1vzYOL-0016sM-0b for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 11:03:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vzYOI-00FdgM-0m for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 11:03:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vzYOH-00FdgE-2l for pgsql-hackers@lists.postgresql.org; Mon, 09 Mar 2026 11:03:14 +0000 Received: from mail-yx1-xb12a.google.com ([2607:f8b0:4864:20::b12a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vzYOF-00000001mk4-3Cmu for pgsql-hackers@lists.postgresql.org; Mon, 09 Mar 2026 11:03:13 +0000 Received: by mail-yx1-xb12a.google.com with SMTP id 956f58d0204a3-64ad8435f46so11029203d50.1 for ; Mon, 09 Mar 2026 04:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773054190; cv=none; d=google.com; s=arc-20240605; b=XF5AjxYGXWRT/hoa7GstIMBmkpjDZkY2Bngfrw6lxqa23UKIA9idqKXQmYZ5xLstJe bUnbf3cGk1Q4OUeBGBGvgE4idRmJn66G9xURFXxB3RlzFNtdH3gHup4aqyE5J/IrR4sx TJ8nEvlM8jABy33xh3Np4nRJzBCdY0k505wsvr1qJjHZse/Vnm6euoPWHed1C7A9kQJj Hncnu0Cvs4Jj5mtdZh1Mmh7mswC0Rrnl3dYzpY/wyW9Y/kz0a7r95JVZUdXWKRFvWJFr MEVpy8g6ScNLX15gtmYD3Bc3YvDuEdkpDR0nxwBoPOtHJhXaglVyig2nWtqeDL45ufQt Povw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ZsjmyQOXG+wiT0+15OGYoqLcEB3EKM1G1z1RO6U0dcU=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=inxnBYc1Zc+C5im/G8J2Ooc/4zLzGGeoXyPiTpuc8YCTiAT360LT9ikGFQWsdr4bFe IS0QJB1h82g41+3VV+JYGPkR8zNjyO0bapx8qcl0vBpQ34hWF3QxlUudgR1wPP57Qt/I CHcaR6jB3WfrNDMHdYP6+3xtvtudLbLlwbulZXXfJdcDsiSXY3ejVuPSm2DiBw3A3Pi8 6Q5WYdTlWkKEnrKhWKzAFFYPkJoFEkd/83900cxzyX5wlvHH7LyWJEE1f9zJLYGK6Wzk 6TlG/yi6mLEPT0QmUoD1shSj6Ir00g+FnA9Ow96hlhfxbfhkn3grTpv9NtnK/zgCHEeg vaIQ==; 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=20230601; t=1773054190; x=1773658990; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ZsjmyQOXG+wiT0+15OGYoqLcEB3EKM1G1z1RO6U0dcU=; b=j1RnnCUGzsez89xyNptsZF5nXKHSEfpz2/RgRXSf0OsNGyajuo+4rSAyU2YqnFuAnL N5IvpcvGRmIyd6K/QcMFFfXQNNUfOnIOjGaRVgYdSA12DmaVSmERbEwZXTvYrN1B9IJF /vKiHhXmoRzE/PvKAk9EzkZ8woM2L5NMdJQt/c0Zg9ZNWVX2rHU6+o5gDDMmdlgBR0+A QZLoRPutD3xwQUQtSvy7OvJMJ7RmgANFnoiFqekCyjN766gdlsHO21VfF7rXDW/dvSVp r+Spm20F9n6WxLIaTd73VL/mWdPeJHzxOR7xUjRjeaKbIYJUYypgQ+hbawKX8JVHErMG 41zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773054190; x=1773658990; h=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=ZsjmyQOXG+wiT0+15OGYoqLcEB3EKM1G1z1RO6U0dcU=; b=sAL6Ol6mIrxtVDs7K/ao5qVVic92cfkUAsrhtvslQbT/Jop8llYkHHA8qZqtepAwYa QFYMfjCYPlu1I9xX2q+sat17t3meKpbEEXkzSTJ9JyLzUrIOsQ4+VxzbhcCL7nKDnSZ/ 0vXHqHgmDHujKXhdNRBhVJDcN2pCkVji30QApGpWhEDrVRWTbJe9JREwzl4JSE0lgZVZ MEELfrTqbbstn765iMxLK0E9sFg4wjIJ6AlDEzEkVybjrrKeGZdYHqbr/aZuOuUPnnzl kWyHSUBNuwKoeVKWIc31yPkZT4jQW02/d7qZj3tu9FCzYsU5BnlBIpfz05TFdNOSLw75 8yVA== X-Gm-Message-State: AOJu0Yyu8bUCvgEub3N16Lrp7UbOlYHQxza57C3KYYZtECAMwY2LPIUL AWtHJlebzSfG949tn53DjyMUmF/E+V0/o/ktsvsBlRpiO8j3SXJnEsOTSSpxCRjzzpWTmSwgGs/ zhlgm+w3NHmEygKwWooSGUl9hu9V6jvV6kWzl X-Gm-Gg: ATEYQzwXNku8/WykKlITfIW5oindqNnRHoS0p4K7D1LbCQJ+Mg4McyP1FI3JyMF8Zkg B4Crew3/4x+IOOh+u1xS15bPpkT+e5jPUGNhUI3/Ag89R2NOrD3ZZI7UuAktfaqQee3Ldrzk1W1 fAvWCzGFVFL2gyPH+yFTYvJkwPaodMDdufNjG9fLiqPnfU8tZVDYipn+bwrCwCDgJbtnLJENEds h6wy0dph8qNbVRugz/24VQW6Jeb3KJJWl8YMMQZKc+exR3mxg4WndpUbEmUgds7iMlneSvLx0DC IIBf+8iUn8Zr+Xkt4w== X-Received: by 2002:a05:690e:191c:b0:64c:a2f7:b49f with SMTP id 956f58d0204a3-64d141d84e9mr10688895d50.35.1773054188556; Mon, 09 Mar 2026 04:03:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shin Berg Date: Mon, 9 Mar 2026 20:02:56 +0900 X-Gm-Features: AaiRm51-Kk910XNhpBB31pT6161VwIEj1FCMh2USk728Kst9dZeEnUHznutZgAs Message-ID: Subject: Re: Inconsistency in owner assignment between INDEX and STATISTICS To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/mixed; boundary="00000000000014f550064c955916" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000014f550064c955916 Content-Type: multipart/alternative; boundary="00000000000014f54f064c955914" --00000000000014f54f064c955914 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Following up on my earlier proposal =E2=80=94 I've gone ahead and written a= patch rather than waiting for feedback. The fix is in CreateStatistics(): after opening the relation, stxowner is set to rel->rd_rel->relowner instead of GetUserId(). The permission check is left using GetUserId() so that only the relation owner (or a superuser) can create statistics, but the ownership recorded in pg_statistic_ext now matches what CREATE INDEX does. A regression test is included in stats_ext.sql to verify that the statistics owner equals the table owner when a superuser creates the statistics object. Patch attached. Thanks, Joshua-Shin On Thu, Feb 26, 2026 at 6:52=E2=80=AFPM Shin Berg wro= te: > Gentle ping on this thread =E2=80=94 any thoughts or concerns about the > proposed alignment? > > Thanks. > > On Sat, Feb 14, 2026 at 5:48=E2=80=AFPM Shin Berg w= rote: > >> Hi, >> >> I'd like to raise a small consistency issue between how INDEX and >> extended STATISTICS handle object ownership, and ask whether aligning th= em >> would be desirable. >> >> Current behavior (tested on REL_17_STABLE): >> >> - When a superuser creates an INDEX on another user's table, the index i= s >> owned by the *table owner* (see catalog/index.c: index relation's relown= er >> is set from the heap relation's relowner). >> - When a superuser creates STATISTICS on another user's table, the >> statistics object is owned by the *current user* (statscmds.c: stxowner = =3D >> GetUserId()). >> >> So in a scenario where a DBA creates both an index and extended >> statistics on a user's table, the table owner can DROP the index (becaus= e >> they own it) but cannot DROP the statistics object (they get "does not >> exist" when lacking ownership, which hides the real permission issue). T= hat >> can cause operational friction in multi-tenant or shared-schema setups >> (e.g. the table owner cannot drop the statistics to resolve dependency >> issues before altering the table). >> >> Reproduction (as superuser, then as table owner): >> >> CREATE SCHEMA shared_schema; >> CREATE USER bob; >> GRANT USAGE, CREATE ON SCHEMA shared_schema TO bob; >> >> SET ROLE bob; >> CREATE TABLE shared_schema.bob_table (a int, b int); >> RESET ROLE; >> >> CREATE INDEX idx_bob ON shared_schema.bob_table(a); >> CREATE STATISTICS stat_bob ON a, b FROM shared_schema.bob_table; >> >> SELECT 'INDEX', c.relname, pg_get_userbyid(c.relowner) FROM pg_index i >> JOIN pg_class c ON c.oid =3D i.indexrelid >> WHERE indrelid =3D 'shared_schema.bob_table'::regclass >> UNION ALL >> SELECT 'STATISTICS', stxname, pg_get_userbyid(stxowner) FROM >> pg_statistic_ext >> WHERE stxrelid =3D 'shared_schema.bob_table'::regclass; >> -- INDEX owner =3D bob, STATISTICS owner =3D superuser >> >> SET ROLE bob; >> DROP INDEX shared_schema.idx_bob; -- succeeds >> DROP STATISTICS shared_schema.stat_bob; -- ERROR: statistics object >> "..." does not exist >> >> I'm not sure if the current STATISTICS ownership behavior was >> intentional. If it wasn't, would it make sense to assign the statistics >> object's owner to the relation owner (same as INDEX) for consistency and= to >> avoid the above scenario? >> >> Thanks for your time. >> > --00000000000014f54f064c955914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Following up on my earlier proposal =E2=80=94 I= 've gone ahead and written a patch
rather than waiting for feedback.=

The fix is in CreateStatistics(): after opening the relation, stxow= ner is
set to rel->rd_rel->relowner instead of GetUserId().=C2=A0 = The permission check
is left using GetUserId() so that only the relation= owner (or a superuser)
can create statistics, but the ownership recorde= d in pg_statistic_ext now
matches what CREATE INDEX does.

A regre= ssion test is included in stats_ext.sql to verify that the
statistics ow= ner equals the table owner when a superuser creates the
statistics objec= t.

Patch attached.

Thanks,
Joshua-Shin

On Thu, Feb 26, 2026 at 6:52=E2=80=AFPM Shin Berg <sjh910805@gmail.com> wrote:
Gentle ping on this= thread =E2=80=94 any thoughts or concerns about the
proposed alignment?=

Thanks.

On Sat, Feb 14, 2026 at 5:48=E2=80=AFPM Shin Berg <sjh910805@gmail.com= > wrote:
Hi,

I'd like to raise a small consistency issue bet= ween how INDEX and extended STATISTICS handle object ownership, and ask whe= ther aligning them would be desirable.

Current behavior (tested on R= EL_17_STABLE):

- When a superuser creates an INDEX on another user&#= 39;s table, the index is owned by the *table owner* (see catalog/index.c: i= ndex relation's relowner is set from the heap relation's relowner).=
- When a superuser creates STATISTICS on another user's table, the = statistics object is owned by the *current user* (statscmds.c: stxowner =3D= GetUserId()).

So in a scenario where a DBA creates both an index an= d extended statistics on a user's table, the table owner can DROP the i= ndex (because they own it) but cannot DROP the statistics object (they get = "does not exist" when lacking ownership, which hides the real per= mission issue). That can cause operational friction in multi-tenant or shar= ed-schema setups (e.g. the table owner cannot drop the statistics to resolv= e dependency issues before altering the table).

Reproduction (as sup= eruser, then as table owner):

=C2=A0 CREATE SCHEMA shared_schema;=C2=A0 CREATE USER bob;
=C2=A0 GRANT USAGE, CREATE ON SCHEMA shared_sch= ema TO bob;

=C2=A0 SET ROLE bob;
=C2=A0 CREATE TABLE shared_schem= a.bob_table (a int, b int);
=C2=A0 RESET ROLE;

=C2=A0 CREATE INDE= X idx_bob ON shared_schema.bob_table(a);
=C2=A0 CREATE STATISTICS stat_b= ob ON a, b FROM shared_schema.bob_table;

=C2=A0 SELECT 'INDEX= 9;, c.relname, pg_get_userbyid(c.relowner) FROM pg_index i
=C2=A0 =C2=A0= JOIN pg_class c ON c.oid =3D i.indexrelid
=C2=A0 =C2=A0 WHERE indrelid = =3D 'shared_schema.bob_table'::regclass
=C2=A0 UNION ALL
=C2= =A0 SELECT 'STATISTICS', stxname, pg_get_userbyid(stxowner) FROM pg= _statistic_ext
=C2=A0 =C2=A0 WHERE stxrelid =3D 'shared_schema.bob_t= able'::regclass;
=C2=A0 -- INDEX owner =3D bob, STATISTICS owner =3D= superuser

=C2=A0 SET ROLE bob;
=C2=A0 DROP INDEX shared_schema.i= dx_bob; =C2=A0 =C2=A0 =C2=A0 =C2=A0-- succeeds
=C2=A0 DROP STATISTICS sh= ared_schema.stat_bob; =C2=A0-- ERROR: statistics object "..." doe= s not exist

I'm not sure if the current STATISTICS ownership beh= avior was intentional. If it wasn't, would it make sense to assign the = statistics object's owner to the relation owner (same as INDEX) for con= sistency and to avoid the above scenario?

Thanks for your time.
--00000000000014f54f064c955914-- --00000000000014f550064c955916 Content-Type: application/octet-stream; name="0001-Make-CREATE-STATISTICS-assign-ownership-to-the-relat.patch" Content-Disposition: attachment; filename="0001-Make-CREATE-STATISTICS-assign-ownership-to-the-relat.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mmj2nnx40 RnJvbSA3MjNkODEwNmE2YWU2MzY2N2Q3NjEzOGIwZGZiMzM4MjRlMDFkZTgwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKb3NodWEtU2hpbiA8c2poOTEwODA1QGdtYWlsLmNvbT4KRGF0 ZTogTW9uLCA5IE1hciAyMDI2IDE5OjU4OjI3ICswOTAwClN1YmplY3Q6IFtQQVRDSF0gTWFrZSBD UkVBVEUgU1RBVElTVElDUyBhc3NpZ24gb3duZXJzaGlwIHRvIHRoZSByZWxhdGlvbiBvd25lcgoK V2hlbiBhIHN1cGVydXNlciBjcmVhdGVzIGV4dGVuZGVkIHN0YXRpc3RpY3Mgb24gYW5vdGhlciB1 c2VyJ3MgdGFibGUsCnRoZSBzdGF0aXN0aWNzIG9iamVjdCB3YXMgb3duZWQgYnkgdGhlIGN1cnJl bnQgdXNlciAoR2V0VXNlcklkKCkpIHJhdGhlcgp0aGFuIHRoZSB0YWJsZSBvd25lci4gIFRoaXMg aXMgaW5jb25zaXN0ZW50IHdpdGggQ1JFQVRFIElOREVYLCB3aGljaAphc3NpZ25zIG93bmVyc2hp cCB0byB0aGUgdGFibGUgb3duZXIgdW5jb25kaXRpb25hbGx5LgoKRml4IGJ5IHNldHRpbmcgc3R4 b3duZXIgdG8gdGhlIHJlbGF0aW9uIG93bmVyIGFmdGVyIHRoZSByZWxhdGlvbiBpcwpvcGVuZWQs IHdoaWxlIGtlZXBpbmcgdGhlIHBlcm1pc3Npb24gY2hlY2sgYWdhaW5zdCBHZXRVc2VySWQoKS4K CkFkZCBhIHJlZ3Jlc3Npb24gdGVzdCB0aGF0IHZlcmlmaWVzIHRoZSBzdGF0aXN0aWNzIG93bmVy IG1hdGNoZXMgdGhlCnRhYmxlIG93bmVyIHdoZW4gY3JlYXRlZCBieSBhIHN1cGVydXNlci4KLS0t CiBzcmMvYmFja2VuZC9jb21tYW5kcy9zdGF0c2NtZHMuYyAgICAgICAgfCAgMyArKy0KIHNyYy90 ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvc3RhdHNfZXh0Lm91dCB8IDE0ICsrKysrKysrKysrKysrCiBz cmMvdGVzdC9yZWdyZXNzL3NxbC9zdGF0c19leHQuc3FsICAgICAgfCAxMCArKysrKysrKysrCiAz IGZpbGVzIGNoYW5nZWQsIDI2IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1n aXQgYS9zcmMvYmFja2VuZC9jb21tYW5kcy9zdGF0c2NtZHMuYyBiL3NyYy9iYWNrZW5kL2NvbW1h bmRzL3N0YXRzY21kcy5jCmluZGV4IGMxZGE3OWYzNmJhLi43NDczMmY5NmViOSAxMDA2NDQKLS0t IGEvc3JjL2JhY2tlbmQvY29tbWFuZHMvc3RhdHNjbWRzLmMKKysrIGIvc3JjL2JhY2tlbmQvY29t bWFuZHMvc3RhdHNjbWRzLmMKQEAgLTE0Miw3ICsxNDIsNyBAQCBDcmVhdGVTdGF0aXN0aWNzKENy ZWF0ZVN0YXRzU3RtdCAqc3RtdCwgYm9vbCBjaGVja19yaWdodHMpCiAJCSAqIGRpZmZlcmVudCBy ZWxhdGlvbiB0aGFuIGEgcHJldmlvdXMgbG9va3VwIGJ5IHRoZSBjYWxsZXIsIHNvIHdlIG11c3QK IAkJICogcGVyZm9ybSB0aGlzIGNoZWNrIGV2ZW4gd2hlbiBjaGVja19yaWdodHMgPT0gZmFsc2Uu CiAJCSAqLwotCQlpZiAoIW9iamVjdF9vd25lcmNoZWNrKFJlbGF0aW9uUmVsYXRpb25JZCwgUmVs YXRpb25HZXRSZWxpZChyZWwpLCBzdHhvd25lcikpCisJCWlmICghb2JqZWN0X293bmVyY2hlY2so UmVsYXRpb25SZWxhdGlvbklkLCBSZWxhdGlvbkdldFJlbGlkKHJlbCksIEdldFVzZXJJZCgpKSkK IAkJCWFjbGNoZWNrX2Vycm9yKEFDTENIRUNLX05PVF9PV05FUiwgZ2V0X3JlbGtpbmRfb2JqdHlw ZShyZWwtPnJkX3JlbC0+cmVsa2luZCksCiAJCQkJCQkgICBSZWxhdGlvbkdldFJlbGF0aW9uTmFt ZShyZWwpKTsKIApAQCAtMTU2LDYgKzE1Niw3IEBAIENyZWF0ZVN0YXRpc3RpY3MoQ3JlYXRlU3Rh dHNTdG10ICpzdG10LCBib29sIGNoZWNrX3JpZ2h0cykKIAogCUFzc2VydChyZWwpOwogCXJlbGlk ID0gUmVsYXRpb25HZXRSZWxpZChyZWwpOworCXN0eG93bmVyID0gcmVsLT5yZF9yZWwtPnJlbG93 bmVyOwogCiAJLyoKIAkgKiBJZiB0aGUgbm9kZSBoYXMgYSBuYW1lLCBzcGxpdCBpdCB1cCBhbmQg ZGV0ZXJtaW5lIGNyZWF0aW9uIG5hbWVzcGFjZS4KZGlmZiAtLWdpdCBhL3NyYy90ZXN0L3JlZ3Jl c3MvZXhwZWN0ZWQvc3RhdHNfZXh0Lm91dCBiL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvc3Rh dHNfZXh0Lm91dAppbmRleCBiNjQzMWQxZWU5NS4uOGRiZTk0YmU1Y2UgMTAwNjQ0Ci0tLSBhL3Ny Yy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvc3RhdHNfZXh0Lm91dAorKysgYi9zcmMvdGVzdC9yZWdy ZXNzL2V4cGVjdGVkL3N0YXRzX2V4dC5vdXQKQEAgLTM1MDksNiArMzUwOSwyMCBAQCBSRVZPS0Ug Q1JFQVRFIE9OIFNDSEVNQSBzdHNfc2NoMSwgc3RzX3NjaDIgRlJPTSByZWdyZXNzX3N0YXRzX3Vz ZXIxOwogU0VUIFNFU1NJT04gQVVUSE9SSVpBVElPTiByZWdyZXNzX3N0YXRzX3VzZXIxOwogQUxU RVIgVEFCTEUgc3RzX3NjaDEudGJsIEFMVEVSIENPTFVNTiBhIFRZUEUgU01BTExJTlQ7CiBBTFRF UiBUQUJMRSBzdHNfc2NoMS50YmwgQUxURVIgQ09MVU1OIGMgU0VUIEVYUFJFU1NJT04gQVMgKGEg KiAzKTsKKy0tIFRlc3QgdGhhdCBzdGF0aXN0aWNzIG93bmVyc2hpcCBmb2xsb3dzIHRoZSB0YWJs ZSBvd25lciB3aGVuIGEgc3VwZXJ1c2VyCistLSBjcmVhdGVzIHN0YXRpc3RpY3Mgb24gYW5vdGhl ciB1c2VyJ3MgdGFibGUsIGNvbnNpc3RlbnQgd2l0aCBDUkVBVEUgSU5ERVguCitSRVNFVCBTRVNT SU9OIEFVVEhPUklaQVRJT047CitDUkVBVEUgVEFCTEUgc3RhdHNfb3duZXJfdGVzdCAoYSBpbnQs IGIgaW50KSBXSVRIIChhdXRvdmFjdXVtX2VuYWJsZWQgPSBvZmYpOworQUxURVIgVEFCTEUgc3Rh dHNfb3duZXJfdGVzdCBPV05FUiBUTyByZWdyZXNzX3N0YXRzX3VzZXIxOworQ1JFQVRFIFNUQVRJ U1RJQ1Mgc3RhdHNfb3duZXJfdGVzdF9zdGF0IE9OIGEsIGIgRlJPTSBzdGF0c19vd25lcl90ZXN0 OworU0VMRUNUIHBnX2dldF91c2VyYnlpZChzdHhvd25lcikgPSAncmVncmVzc19zdGF0c191c2Vy MScgQVMgb3duZXJfaXNfdGFibGVfb3duZXIKK0ZST00gcGdfc3RhdGlzdGljX2V4dCBXSEVSRSBz dHhuYW1lID0gJ3N0YXRzX293bmVyX3Rlc3Rfc3RhdCc7Cisgb3duZXJfaXNfdGFibGVfb3duZXIg CistLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisgdAorKDEgcm93KQorCitEUk9QIFRBQkxFIHN0YXRz X293bmVyX3Rlc3Q7CiAtLSBUaWR5IHVwCiBEUk9QIE9QRVJBVE9SIDw8PCAoaW50LCBpbnQpOwog RFJPUCBGVU5DVElPTiBvcF9sZWFrKGludCwgaW50KTsKZGlmZiAtLWdpdCBhL3NyYy90ZXN0L3Jl Z3Jlc3Mvc3FsL3N0YXRzX2V4dC5zcWwgYi9zcmMvdGVzdC9yZWdyZXNzL3NxbC9zdGF0c19leHQu c3FsCmluZGV4IDlkY2NlMzQ0MGM4Li5iZTE0YzgyNzQzZSAxMDA2NDQKLS0tIGEvc3JjL3Rlc3Qv cmVncmVzcy9zcWwvc3RhdHNfZXh0LnNxbAorKysgYi9zcmMvdGVzdC9yZWdyZXNzL3NxbC9zdGF0 c19leHQuc3FsCkBAIC0xNzk1LDYgKzE3OTUsMTYgQEAgU0VUIFNFU1NJT04gQVVUSE9SSVpBVElP TiByZWdyZXNzX3N0YXRzX3VzZXIxOwogQUxURVIgVEFCTEUgc3RzX3NjaDEudGJsIEFMVEVSIENP TFVNTiBhIFRZUEUgU01BTExJTlQ7CiBBTFRFUiBUQUJMRSBzdHNfc2NoMS50YmwgQUxURVIgQ09M VU1OIGMgU0VUIEVYUFJFU1NJT04gQVMgKGEgKiAzKTsKIAorLS0gVGVzdCB0aGF0IHN0YXRpc3Rp Y3Mgb3duZXJzaGlwIGZvbGxvd3MgdGhlIHRhYmxlIG93bmVyIHdoZW4gYSBzdXBlcnVzZXIKKy0t IGNyZWF0ZXMgc3RhdGlzdGljcyBvbiBhbm90aGVyIHVzZXIncyB0YWJsZSwgY29uc2lzdGVudCB3 aXRoIENSRUFURSBJTkRFWC4KK1JFU0VUIFNFU1NJT04gQVVUSE9SSVpBVElPTjsKK0NSRUFURSBU QUJMRSBzdGF0c19vd25lcl90ZXN0IChhIGludCwgYiBpbnQpIFdJVEggKGF1dG92YWN1dW1fZW5h YmxlZCA9IG9mZik7CitBTFRFUiBUQUJMRSBzdGF0c19vd25lcl90ZXN0IE9XTkVSIFRPIHJlZ3Jl c3Nfc3RhdHNfdXNlcjE7CitDUkVBVEUgU1RBVElTVElDUyBzdGF0c19vd25lcl90ZXN0X3N0YXQg T04gYSwgYiBGUk9NIHN0YXRzX293bmVyX3Rlc3Q7CitTRUxFQ1QgcGdfZ2V0X3VzZXJieWlkKHN0 eG93bmVyKSA9ICdyZWdyZXNzX3N0YXRzX3VzZXIxJyBBUyBvd25lcl9pc190YWJsZV9vd25lcgor RlJPTSBwZ19zdGF0aXN0aWNfZXh0IFdIRVJFIHN0eG5hbWUgPSAnc3RhdHNfb3duZXJfdGVzdF9z dGF0JzsKK0RST1AgVEFCTEUgc3RhdHNfb3duZXJfdGVzdDsKKwogLS0gVGlkeSB1cAogRFJPUCBP UEVSQVRPUiA8PDwgKGludCwgaW50KTsKIERST1AgRlVOQ1RJT04gb3BfbGVhayhpbnQsIGludCk7 Ci0tIAoyLjUyLjAKCg== --00000000000014f550064c955916--