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 1waTqc-001pm7-12 for pgsql-bugs@arkaria.postgresql.org; Fri, 19 Jun 2026 07:41:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1waTqZ-00FTDB-2X for pgsql-bugs@arkaria.postgresql.org; Fri, 19 Jun 2026 07:41:03 +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 1waTqZ-00FTD3-1T for pgsql-bugs@lists.postgresql.org; Fri, 19 Jun 2026 07:41:03 +0000 Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1waTqX-00000001EeY-01Mr for pgsql-bugs@lists.postgresql.org; Fri, 19 Jun 2026 07:41:03 +0000 Received: by mail-ot1-x333.google.com with SMTP id 46e09a7af769-7e6cfdc8382so1357405a34.2 for ; Fri, 19 Jun 2026 00:41:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781854858; cv=none; d=google.com; s=arc-20240605; b=cT6QuuIa1TqJgw6dYY8Mx+Gl7H7MTKy2DmU9Ay95ZeE96hV494pIa81OHd4zPy5uNi skNof4mIaOBP7bXTVIoHGvRQ6fOv7A000B9ylh8YS6Krig1jA45IOnwo26/BR+yqLdOH BW620nvu4E6GwjeCpnGl8F7TNcQRVAkL/IRSIfMblPutU5UPb1A1eu5L0Bzl54PiV/rv D5xyA97Rlu/gZ1huHdlF4SkEsZDjtUQ71eUlDlzv2hWRbTMp9z1BybvGj3CHhFjF2Y6G SpCmqqVufVls9UoEnF8IBafUyYySQBdzJ0SZkvbfGqVun4VjeWIBiCbiVaxBHKWSYeLc tREg== 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=Tf7/NXK/1RxzDtwqMysJVpXptoLP6Pqjq6K65/szWN8=; fh=KvdZdn3l6ia178OngkoxvsI8NB7RgxRk8Xa0V2zHTEM=; b=TnXB+8T1uAaWQyGerdf/GJq5fJtLnZhGNeAVWmhWGM9f9nMYwKKHCxsMHxK4aVHudf f99P8fZDATIoDaHtYJtpcrcwpsG8xfQshtKBF1mnhpADjoE+D4tVIc4X3NA02KskC2bI RZhid1EOvg4dQoYQs+O8i++Gh77ec6o2ZwXG5B5FAjLtDU0UKJ+ZJh4acmiOzlU7xm0O kt/TkHwXnmWOJh1xvZm2Br5RCVAK8gqPDxv74vcyPNj1IWGvFczdty0wHDiVRl7PRnAB fsUo/RCWe3sGQ8tNt8PyUS4cI38Z7dz+mSLvED6vonh97lRQvp5bonsGriQuUBfF5a08 jhww==; 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=1781854858; x=1782459658; 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=Tf7/NXK/1RxzDtwqMysJVpXptoLP6Pqjq6K65/szWN8=; b=H43ujjeJ9MX5X7u7Ohq349I72SFuah92y0HETKzk3YfJUn+WWmoTNWtBvIZJkUCq1n +8PzZwzk+cjqGKqaaWTqCjnmYejSS1En6LFp/aVbwauWg4BdHdbBnxKdcSjRU5Rc1c5O bgPPf1+SyuordEBdrpMvdlpbDvQky6WMSss4jjV/YogZEJwPMJ+qZNnkFRPII3o+4Wdk ia8ECpakdRzV+s57NuAEYEe/EDn8wYa1ifltxUckzzS05fV6mYE+b/QcbKP1Qr4EiI4d qLYu9NfZipokYnhnmVv2uJqtLKHBnBz7dUOWnyJqReQfnSDsF9vCh0CcdY+5q1tvRj9f A/TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781854858; x=1782459658; 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=Tf7/NXK/1RxzDtwqMysJVpXptoLP6Pqjq6K65/szWN8=; b=nuZkl2Zz20725khM1CNC53cE6VC6mrtnZM/AfXSB3V1Nv24ykmRmzVRM5FPmDo1Dwl NfL/RkktCUlVTEW2txmuVq4xA1Ps2SCV+czzB6zffxr6mJy7uI/7OmiKRlxfxdtr29nc JuVQNJMTYvVPKDW85T9MQ391g1UN+SwkifX4yFPYp9LrGXMMpovee7VoJ9nU/OtMF71J VPA2Rxro9cF5Fni5V2vot5KSSGgYdXg2ypwjIkTnXzngHDAAQO011GLPih8L7xfkh0K3 q7q78oaUyJwR/2UdU4pMqPdP0yDD4yGIfTb5Z9DWEKK9yauOrXXt/HZYjnFPCRci66rz AUAA== X-Forwarded-Encrypted: i=1; AFNElJ8oFD3/pClHyW0xFljjlUJ7sGEEWWVaJKnA6BrV0a3NwnJuQkQSeAsKHaRCmgIzlHJMy+rw7U+aznSA@lists.postgresql.org X-Gm-Message-State: AOJu0YzMJBJNx4V8a36KN0ODYeyrli7MATfEE6A4kpkeRWviPPLMEJL4 1HUNKPK0c+q/doro1wgvqF6knsMZyH8TiqG9ta8lplCz8Ov6P8dxxawww0+sJrac47f2FhpcyLM uUCGNCsSw1wz7DdhetQi5EFIzOIn1QpE= X-Gm-Gg: AfdE7ckD7XbBwCX1mPJYkWhjd7qFuRPA2RyeZqvNjRIHdfJghNLkBZA94zi0jEFg3Gk 0RcEx5higgw1ljJqJu7hCEE4g7WHNBgPlYyPB3yT3iCrqwhVW5q4pPqugE7e/NFL8Oa7Mynl/DO n12chF4txXmfOts0P0r6rck9/FLMGL4W1iZb4oxeacdcupuwSswkWE48KboiZB2BfqkYOZDwwJ2 MkWtAbu3M5EQDH8LcuLPaKp+8Kst3y7kqh+MqBPaNWMLbUJaO7n2w5I6wYBfZ6HN2bx/qM1Yfvu 6aGVdyWTZg2kBjiFm1VGoHouXX+WpKbWbhhGVUO9BWrAsZXe9biQj19sOQlkbL4Oqv8fpwLlAAj 8AgyLCkctpXW+0ioq X-Received: by 2002:a05:6808:130b:b0:485:7c5a:63bc with SMTP id 5614622812f47-4896a9e96bcmr2467101b6e.6.1781854858179; Fri, 19 Jun 2026 00:40:58 -0700 (PDT) MIME-Version: 1.0 References: <19483-80de42dc4e62cfd6@postgresql.org> <104812.1780847519@sss.pgh.pa.us> In-Reply-To: From: =?UTF-8?Q?H=C3=BCseyin_Demir?= Date: Fri, 19 Jun 2026 09:40:47 +0200 X-Gm-Features: AVVi8CdKzsoSkI5barmzcRUkgDNkDSZWZgul600Ne0tAxB8tOj192lZVhJvmhVA Message-ID: Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table To: Tom Lane Cc: Greg Sabino Mullane , pgsql-bugs@lists.postgresql.org, Laurenz Albe Content-Type: multipart/mixed; boundary="000000000000dd432106549669d4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000dd432106549669d4 Content-Type: multipart/alternative; boundary="000000000000dd431f06549669d2" --000000000000dd431f06549669d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Found a problem and fixed it quickly. v2 introduced a regression: the new query in getAdditionalACLs() joined pg_catalog.pg_authid to check whether a grantee OID still exists. pg_authid is restricted to superusers because it stores password hashes. That caused pg_dump to fail with "permission denied for table pg_authid" whenever it ran as a non-superuser role v3 fixes this by joining pg_catalog.pg_roles instead. pg_roles is a view defined directly on top of pg_authid. Since we only need to check whether a row with a given OID exists, pg_roles is sufficient and correct here. H=C3=BCseyin Demir , 19 Haz 2026 Cum, 08:25 tarihind= e =C5=9Funu yazd=C4=B1: > I simplified the patch and only changed the SQL query. > > > The v2 patch correctly filters `pg_init_privs` entries whose grantee OID > has no corresponding row in `pg_authid`, without affecting valid entries. > > Regards, > Demir. > > H=C3=BCseyin Demir , 12 Haz 2026 Cum, 18:22 tarihi= nde > =C5=9Funu yazd=C4=B1: > >> Hi, >> >> I worked on pg_dump and discussed it with Laurenz Albe. Created the >> attached patch. >> >> The fix filters dangling grantees out of each initprivs array at query >> time, using NULLIF/ARRAY/NOT EXISTS against pg_authid. Entries for >> grantee =3D 0 (PUBLIC) are never filtered. If all entries for an object >> are dangling, NULL is returned and no ACL statement is emitted. Since >> we cannot restore grants to non-existent roles. correct outcome, >> >> The patch includes a TAP test (008_pg_dump_dangling_initprivs.pl) that >> reproduces the scenario using allow_system_table_mods to create a >> dangling pg_init_privs entry, then verifies pg_dump exits cleanly and >> emits no invalid GRANT. >> >> I have not prepared backpatch branches yet. >> >> Regards. >> >> H=C3=BCseyin Demir , 11 Haz 2026 Per, 07:49 >> tarihinde =C5=9Funu yazd=C4=B1: >> > >> > > The orphaned-rows problem shouldn't exist in v17 and later (see >> > > 534287403, 35dd40d34, and related commits). The OP is apparently >> > > complaining about an upgrade from v14, where such rows could exist. >> > >> > Yes I was working on upgrading the PostgreSQL version from v14 to v18 >> > and was able to solve the problem by removing the danling records from >> > pg_init_privs. >> > >> > > I wonder if it'd be sane for pg_dump to just skip dangling role >> > > references in pg_init_privs. >> > >> > It will change the behavior of pg_dump and it's a general purpose tool >> > because when we instruct pg_dump to filter orphan records it will >> > change the content in the system catalogs. >> > >> > For now I suppose we have two options: either pg_upgrade or pg_dump. >> > >> > Regards. >> > >> > >> > Tom Lane , 7 Haz 2026 Paz, 17:52 tarihinde =C5=9Fun= u >> yazd=C4=B1: >> > > >> > > Greg Sabino Mullane writes: >> > > >> 5. Verify orphan records remain in pg_init_privs: >> > > >> > > > Thanks for providing a failing use case. I ran this on a 18.3 >> server and >> > > > found no orphaned rows - but I used the pg_stat_statements extensi= on >> > > > instead of pg_wait_sampling. Could you try your experiment using >> > > > pg_stat_statements? And could you also show us the contents of the >> errant >> > > > rows in pg_init_privs for the failing case? >> > > >> > > The orphaned-rows problem shouldn't exist in v17 and later (see >> > > 534287403, 35dd40d34, and related commits). The OP is apparently >> > > complaining about an upgrade from v14, where such rows could exist. >> > > >> > > I don't especially care for the proposed fix of making pg_upgrade >> > > refuse to run. Manually correcting such situations would be tedious >> > > and error-prone. Plus, it's inconsistent with what we did about >> > > related issues with role GRANTs (see 29d75b25b and 74b4438a7). >> > > I wonder if it'd be sane for pg_dump to just skip dangling role >> > > references in pg_init_privs. >> > > >> > > regards, tom lane >> > --000000000000dd431f06549669d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Found a problem and fixed it quickly.=C2=A0

v2 intr= oduced a regression: the new query in getAdditionalACLs() joined pg_catalog= .pg_authid to check whether a grantee OID still exists. pg_authid is restri= cted to superusers because it stores password hashes. That caused pg_dump t= o fail with "permission denied for table pg_authid" whenever it r= an as a non-superuser role

v3 fixes this by joining pg_catalog.pg_ro= les instead. pg_roles is a view defined directly on top of pg_authid. Since= we only need to check whether a row with a given OID exists, pg_roles is s= ufficient and correct here.



H=C3=BCseyin Demir <huseyin= .d3r@gmail.com>, 19 Haz 2026 Cum, 08:25 tarihinde =C5=9Funu yazd=C4= =B1:
I simplified the patch and only changed the SQL query.=C2=A0


The v2 patch correctly filters `pg_init_pri= vs` entries whose grantee OID has no corresponding row in `pg_authid`, with= out affecting valid entries.

Regards,
Demir.
H=C3= =BCseyin Demir <huseyin.d3r@gmail.com>, 12 Haz 2026 Cum, 18:22 tarihinde =C5=9Fun= u yazd=C4=B1:
Hi= ,

I worked on pg_dump and discussed it with Laurenz Albe. Created the
attached patch.

The fix filters dangling grantees out of each initprivs array at query
time, using NULLIF/ARRAY/NOT EXISTS against pg_authid. Entries for
grantee =3D 0 (PUBLIC) are never filtered. If all entries for an object
are dangling, NULL is returned and no ACL statement is emitted. Since
we cannot restore grants to non-existent roles. correct outcome,

The patch includes a TAP test (008_pg_dump_dangling_initpriv= s.pl) that
reproduces the scenario using allow_system_table_mods to create a
dangling pg_init_privs entry, then verifies pg_dump exits cleanly and
emits no invalid GRANT.

I have not prepared backpatch branches yet.

Regards.

H=C3=BCseyin Demir <huseyin.d3r@gmail.com>, 11 Haz 2026 Per, 07:49
tarihinde =C5=9Funu yazd=C4=B1:
>
> > The orphaned-rows problem shouldn't exist in v17 and later (s= ee
> > 534287403, 35dd40d34, and related commits).=C2=A0 The OP is appar= ently
> > complaining about an upgrade from v14, where such rows could exis= t.
>
> Yes I was working on upgrading the PostgreSQL version from v14 to v18<= br> > and was able to solve the problem by removing the danling records from=
> pg_init_privs.
>
> > I wonder if it'd be sane for pg_dump to just skip dangling ro= le
> > references in pg_init_privs.
>
> It will change the behavior of pg_dump and it's a general purpose = tool
> because when we instruct pg_dump to filter orphan records it will
> change the content in the system catalogs.
>
> For now I suppose we have two options: either pg_upgrade or pg_dump. >
> Regards.
>
>
> Tom Lane <tg= l@sss.pgh.pa.us>, 7 Haz 2026 Paz, 17:52 tarihinde =C5=9Funu yazd=C4= =B1:
> >
> > Greg Sabino Mullane <htamfids@gmail.com> writes:
> > >> 5. Verify orphan records remain in pg_init_privs:
> >
> > > Thanks for providing a failing use case. I ran this on a 18.= 3 server and
> > > found no orphaned rows - but I used the pg_stat_statements e= xtension
> > > instead of pg_wait_sampling. Could you try your experiment u= sing
> > > pg_stat_statements? And could you also show us the contents = of the errant
> > > rows in pg_init_privs for the failing case?
> >
> > The orphaned-rows problem shouldn't exist in v17 and later (s= ee
> > 534287403, 35dd40d34, and related commits).=C2=A0 The OP is appar= ently
> > complaining about an upgrade from v14, where such rows could exis= t.
> >
> > I don't especially care for the proposed fix of making pg_upg= rade
> > refuse to run.=C2=A0 Manually correcting such situations would be= tedious
> > and error-prone.=C2=A0 Plus, it's inconsistent with what we d= id about
> > related issues with role GRANTs (see 29d75b25b and 74b4438a7). > > I wonder if it'd be sane for pg_dump to just skip dangling ro= le
> > references in pg_init_privs.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0regards, tom lane
--000000000000dd431f06549669d2-- --000000000000dd432106549669d4 Content-Type: application/octet-stream; name="v3-0001-pg_dump-skip-dangling-initprivs.patch" Content-Disposition: attachment; filename="v3-0001-pg_dump-skip-dangling-initprivs.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mqkmcxan0 RnJvbSA5MmMxNzVjZjk0YTVlNjNlNzc3NjdlNTUyYzUxMTAyMDcxMWNiNzEyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIdXNleWluIERlbWlyIDxodXNleWluLmQzckBnbWFpbC5jb20+ CkRhdGU6IEZyaSwgMTkgSnVuIDIwMjYgMDc6Mzk6MjIgKzAyMDAKU3ViamVjdDogW1BBVENIXSBw Z19kdW1wOiBza2lwIHBnX2luaXRfcHJpdnMgZW50cmllcyBmb3Igbm9uLWV4aXN0ZW50IHJvbGVz Ck1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYt OApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpwZ19pbml0X3ByaXZzLCBpbnRyb2R1 Y2VkIGluIFBvc3RncmVTUUwgOS42LCByZWNvcmRzIHRoZSAiaW5pdGlhbCIKcHJpdmlsZWdlIHN0 YXRlIG9mIG9iamVjdHMg4oCUIGVpdGhlciBzZXQgYnkgaW5pdGRiIChwcml2dHlwZSAnaScpIG9y IGJ5CkNSRUFURSBFWFRFTlNJT04gc2NyaXB0cyAocHJpdnR5cGUgJ2UnKS4gIHBnX2R1bXAgcmVh ZHMgdGhpcyBjYXRhbG9nIHRvCmRldGVybWluZSB3aGljaCBBQ0wgY2hhbmdlcyB0aGUgdXNlciBt YWRlIG9uIHRvcCBvZiB0aGUgZGVmYXVsdHMsIHNvIGl0CmNhbiBlbWl0IHRoZSByaWdodCBHUkFO VC9SRVZPS0Ugc3RhdGVtZW50cy4KCkJlZm9yZSBjb21taXQgNTM0Mjg3NDAzOTEsIFBvc3RncmVT UUwgZGlkIG5vdCByZWNvcmQgcm9sZSBkZXBlbmRlbmNpZXMKZm9yIHBnX2luaXRfcHJpdnMgZW50 cmllcyBpbiBwZ19zaGRlcGVuZCwgbWVhbmluZyBEUk9QIFJPTEUgY291bGQgbGVhdmUKYmVoaW5k IEFDTCBlbnRyaWVzIHdob3NlIGdyYW50ZWUgT0lEIG5vIGxvbmdlciBleGlzdHMgaW4gcGdfYXV0 aGlkLgpDcm9zcy1jbHVzdGVyIHJlc3RvcmVzIChkdW1waW5nIGZyb20gb25lIHN5c3RlbSB3aGVy ZSBhIHJvbGUgZXhpc3RlZCwKcmVzdG9yaW5nIHRvIGFub3RoZXIgd2hlcmUgaXQgZG9lcyBub3Qp IGNhbiBwcm9kdWNlIHRoZSBzYW1lIHNpdHVhdGlvbgpldmVuIG9uIG1vZGVybiByZWxlYXNlcy4K ClRoZSBvbGQgY29kZSBwYXNzZWQgdGhlc2UgZGFuZ2xpbmcgYWNsaXRlbSBlbnRyaWVzIHRocm91 Z2ggdW5jaGFuZ2VkLApjYXVzaW5nIHBnX2R1bXAgdG8gZW1pdCBzdGF0ZW1lbnRzIHN1Y2ggYXMK CiAgICBHUkFOVCBFWEVDVVRFIE9OIEZVTkNUSU9OIGZvbygpIFRPICI4Nzg2OCI7Cgp3aGVyZSAi ODc4NjgiIGlzIGEgbnVtZXJpYyBPSUQg4oCUIGludmFsaWQgU1FMIHRoYXQgd291bGQgZmFpbCBv biByZXN0b3JlLgoKRml4IGJ5IGZpbHRlcmluZyBkYW5nbGluZyBncmFudGVlcyBvdXQgb2YgZWFj aCBpbml0cHJpdnMgYXJyYXkgYXQgcXVlcnkKdGltZTogZm9yIGV2ZXJ5IGFjbGl0ZW0gd2hvc2Ug Z3JhbnRlZSBPSUQgZG9lcyBub3QgYXBwZWFyIGluIHBnX2F1dGhpZAooZXhjbHVkaW5nIGdyYW50 ZWUgPSAwLCB3aGljaCBtZWFucyBQVUJMSUMpLCB0aGUgZW50cnkgaXMgc2lsZW50bHkKZHJvcHBl ZC4gIElmIGFsbCBlbnRyaWVzIGZvciBhbiBvYmplY3QgYXJlIGRhbmdsaW5nIHRoZSByZXN1bHQg aXMgTlVMTAphbmQgbm8gQUNMIGlzIGVtaXR0ZWQsIHdoaWNoIGlzIGNvcnJlY3Qg4oCUIHdlIGNh bm5vdCByZXN0b3JlIGdyYW50cyB0bwpyb2xlcyB0aGF0IGRvIG5vdCBleGlzdC4KCkEgc2ltaWxh ciBpc3N1ZSBpbiBwZ19kdW1wYWxsIHdhcyBmaXhlZCBieSBjb21taXQgNzRiNDQzOGE3MGIuCgpU aGlzIGJ1ZyBoYXMgZXhpc3RlZCBzaW5jZSBwZ19pbml0X3ByaXZzIHdhcyBpbnRyb2R1Y2VkIGlu IDkuNi4KQmFja3BhdGNoIHRvIDE0IChvbGRlc3QgY3VycmVudGx5IHN1cHBvcnRlZCBicmFuY2gp LgoKQXV0aG9yOiBIdXNleWluIERlbWlyIDxodXNleWluLmQzckBnbWFpbC5jb20+CkRpc2N1c3Np b246IGh0dHBzOi8vcG9zdGdyLmVzL20vMTk0ODMtODBkZTQyZGM0ZTYyY2ZkNiU0MHBvc3RncmVz cWwub3JnCkJhY2twYXRjaC10aHJvdWdoOiAxNAotLS0KIHNyYy9iaW4vcGdfZHVtcC9wZ19kdW1w LmMgICAgICAgICAgICAgICAgICAgICB8IDE0ICsrKy0KIC4uLi90LzAwOF9wZ19kdW1wX2Rhbmds aW5nX2luaXRwcml2cy5wbCAgICAgICB8IDc2ICsrKysrKysrKysrKysrKysrKysKIDIgZmlsZXMg Y2hhbmdlZCwgODggaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEw MDY0NCBzcmMvYmluL3BnX2R1bXAvdC8wMDhfcGdfZHVtcF9kYW5nbGluZ19pbml0cHJpdnMucGwK CmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2R1bXAvcGdfZHVtcC5jIGIvc3JjL2Jpbi9wZ19kdW1w L3BnX2R1bXAuYwppbmRleCBhMGY3ZjhlMjE2OC4uMDNiMzkwODE5MzAgMTAwNjQ0Ci0tLSBhL3Ny Yy9iaW4vcGdfZHVtcC9wZ19kdW1wLmMKKysrIGIvc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXAuYwpA QCAtMTA5MDAsOCArMTA5MDAsMTggQEAgZ2V0QWRkaXRpb25hbEFDTHMoQXJjaGl2ZSAqZm91dCkK IAlpZiAoZm91dC0+cmVtb3RlVmVyc2lvbiA+PSA5MDYwMCkKIAl7CiAJCXByaW50ZlBRRXhwQnVm ZmVyKHF1ZXJ5LAotCQkJCQkJICAiU0VMRUNUIG9iam9pZCwgY2xhc3NvaWQsIG9ianN1YmlkLCBw cml2dHlwZSwgaW5pdHByaXZzICIKLQkJCQkJCSAgIkZST00gcGdfaW5pdF9wcml2cyIpOworCQkJ CQkJICAiU0VMRUNUIHBpcC5vYmpvaWQsIHBpcC5jbGFzc29pZCwgcGlwLm9ianN1YmlkLCBwaXAu cHJpdnR5cGUsXG4iCisJCQkJCQkgICIgIE5VTExJRihcbiIKKwkJCQkJCSAgIiAgICBBUlJBWShc biIKKwkJCQkJCSAgIiAgICAgIFNFTEVDVCBlbHQgRlJPTSBwZ19jYXRhbG9nLnVubmVzdChwaXAu aW5pdHByaXZzKSBBUyBlbHRcbiIKKwkJCQkJCSAgIiAgICAgIFdIRVJFIE5PVCBFWElTVFMgKFxu IgorCQkJCQkJICAiICAgICAgICBTRUxFQ1QgMSBGUk9NIHBnX2NhdGFsb2cuYWNsZXhwbG9kZShB UlJBWVtlbHRdKSBhY2VcbiIKKwkJCQkJCSAgIiAgICAgICAgTEVGVCBKT0lOIHBnX2NhdGFsb2cu cGdfcm9sZXMgYSBPTiBhLm9pZCA9IGFjZS5ncmFudGVlXG4iCisJCQkJCQkgICIgICAgICAgIFdI RVJFIGFjZS5ncmFudGVlIDw+IDAgQU5EIGEub2lkIElTIE5VTExcbiIKKwkJCQkJCSAgIiAgICAg IClcbiIKKwkJCQkJCSAgIiAgICApLCBBUlJBWVtdOjpwZ19jYXRhbG9nLmFjbGl0ZW1bXVxuIgor CQkJCQkJICAiICApIEFTIGluaXRwcml2c1xuIgorCQkJCQkJICAiRlJPTSBwZ19jYXRhbG9nLnBn X2luaXRfcHJpdnMgcGlwIik7CiAKIAkJcmVzID0gRXhlY3V0ZVNxbFF1ZXJ5KGZvdXQsIHF1ZXJ5 LT5kYXRhLCBQR1JFU19UVVBMRVNfT0spOwogCmRpZmYgLS1naXQgYS9zcmMvYmluL3BnX2R1bXAv dC8wMDhfcGdfZHVtcF9kYW5nbGluZ19pbml0cHJpdnMucGwgYi9zcmMvYmluL3BnX2R1bXAvdC8w MDhfcGdfZHVtcF9kYW5nbGluZ19pbml0cHJpdnMucGwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5k ZXggMDAwMDAwMDAwMDAuLmY0ZTkwY2FkY2E2Ci0tLSAvZGV2L251bGwKKysrIGIvc3JjL2Jpbi9w Z19kdW1wL3QvMDA4X3BnX2R1bXBfZGFuZ2xpbmdfaW5pdHByaXZzLnBsCkBAIC0wLDAgKzEsNzYg QEAKKyMgQ29weXJpZ2h0IChjKSAyMDI0LTIwMjYsIFBvc3RncmVTUUwgR2xvYmFsIERldmVsb3Bt ZW50IEdyb3VwCisjCisjIFRlc3RzIHRoYXQgcGdfZHVtcCBzaWxlbnRseSBza2lwcyBwZ19pbml0 X3ByaXZzIGVudHJpZXMgdGhhdCByZWZlcmVuY2UKKyMgcm9sZXMgbm8gbG9uZ2VyIHByZXNlbnQg aW4gcGdfYXV0aGlkLCByYXRoZXIgdGhhbiBlbWl0dGluZyBpbnZhbGlkIEdSQU5UCisjIHN0YXRl bWVudHMgd2l0aCBudW1lcmljIE9JRHMgYXMgcm9sZSBuYW1lcy4KKwordXNlIHN0cmljdDsKK3Vz ZSB3YXJuaW5ncyBGQVRBTCA9PiAnYWxsJzsKKwordXNlIFBvc3RncmVTUUw6OlRlc3Q6OkNsdXN0 ZXI7Cit1c2UgUG9zdGdyZVNRTDo6VGVzdDo6VXRpbHM7Cit1c2UgVGVzdDo6TW9yZTsKKworbXkg JG5vZGUgPSBQb3N0Z3JlU1FMOjpUZXN0OjpDbHVzdGVyLT5uZXcoJ21haW4nKTsKKyRub2RlLT5p bml0OworJG5vZGUtPnN0YXJ0OworCiskbm9kZS0+c2FmZV9wc3FsKCdwb3N0Z3JlcycsICdDUkVB VEUgREFUQUJBU0UgcmVncmVzc19kYW5nbGluZycpOworCisjIFNpbXVsYXRlIGFuIGV4dGVuc2lv bi1pbnN0YWxsZWQgb2JqZWN0IHdob3NlIGluaXRwcml2cyByZWZlcmVuY2VkIGEgcm9sZQorIyB0 aGF0IHdhcyBsYXRlciBkcm9wcGVkIChvciBuZXZlciBleGlzdGVkIG9uIHRoaXMgY2x1c3Rlciku ICBXZSBjYW5ub3QgdXNlCisjIG5vcm1hbCBEUk9QIFJPTEUgYmVjYXVzZSBwZ19zaGRlcGVuZCB3 b3VsZCBibG9jayBpdCwgc28gd2UgZGVsZXRlIHRoZSByb2xlCisjIGRpcmVjdGx5IGZyb20gcGdf YXV0aGlkIHdpdGggYWxsb3dfc3lzdGVtX3RhYmxlX21vZHMsIGxlYXZpbmcgYSBkYW5nbGluZwor IyBncmFudGVlIE9JRCBpbiBwZ19pbml0X3ByaXZzLgorJG5vZGUtPnNhZmVfcHNxbCgKKwkncmVn cmVzc19kYW5nbGluZycsCisJcXsKK1NFVCBhbGxvd19zeXN0ZW1fdGFibGVfbW9kcyA9IHRydWU7 CisKK0NSRUFURSBST0xFIGdob3N0X3JvbGU7CisKK0NSRUFURSBGVU5DVElPTiBwdWJsaWMudGVz dF9mdW5jKCkgUkVUVVJOUyBpbnQgTEFOR1VBR0Ugc3FsIEFTICdTRUxFQ1QgMSc7CisKK0lOU0VS VCBJTlRPIHBnX2luaXRfcHJpdnMgKG9iam9pZCwgY2xhc3NvaWQsIG9ianN1YmlkLCBwcml2dHlw ZSwgaW5pdHByaXZzKQorU0VMRUNUIHAub2lkLAorICAgICAgIChTRUxFQ1Qgb2lkIEZST00gcGdf Y2xhc3MgV0hFUkUgcmVsbmFtZSA9ICdwZ19wcm9jJyksCisgICAgICAgMCwKKyAgICAgICAnZScs CisgICAgICAgQVJSQVlbKCdnaG9zdF9yb2xlPVgvJyB8fCBjdXJyZW50X3VzZXIpOjphY2xpdGVt XQorRlJPTSAgIHBnX3Byb2MgcAorV0hFUkUgIHAucHJvbmFtZSA9ICd0ZXN0X2Z1bmMnCitBTkQg ICAgcC5wcm9uYW1lc3BhY2UgPSAncHVibGljJzo6cmVnbmFtZXNwYWNlOworCitERUxFVEUgRlJP TSBwZ19hdXRoaWQgV0hFUkUgcm9sbmFtZSA9ICdnaG9zdF9yb2xlJzsKK30pOworCitteSAkdGVt cGRpciAgID0gUG9zdGdyZVNRTDo6VGVzdDo6VXRpbHM6OnRlbXBkaXI7CitteSAkZHVtcF9maWxl ID0gIiR0ZW1wZGlyL2RhbmdsaW5nLnNxbCI7CisKKyMgcGdfZHVtcCBtdXN0IHN1Y2NlZWQgZXZl biB0aG91Z2ggcGdfaW5pdF9wcml2cyBoYXMgYSBkYW5nbGluZyBncmFudGVlIE9JRC4KK2NvbW1h bmRfb2soCisJWworCQkncGdfZHVtcCcsCisJCSctLXBvcnQnICAgICAgICA9PiAkbm9kZS0+cG9y dCwKKwkJJy0tc2NoZW1hLW9ubHknLAorCQknLWYnICAgICAgICAgICAgPT4gJGR1bXBfZmlsZSwK KwkJJ3JlZ3Jlc3NfZGFuZ2xpbmcnLAorCV0sCisJJ3BnX2R1bXAgc3VjY2VlZHMgd2l0aCBkYW5n bGluZyBwZ19pbml0X3ByaXZzIGVudHJpZXMnKTsKKworbXkgJGR1bXAgPSBzbHVycF9maWxlKCRk dW1wX2ZpbGUpOworCisjIFRoZSBmdW5jdGlvbiBpdHNlbGYgbXVzdCBzdGlsbCBhcHBlYXIgaW4g dGhlIGR1bXAuCitsaWtlKCRkdW1wLCBxci9DUkVBVEUgRlVOQ1RJT04gcHVibGljXC50ZXN0X2Z1 bmMvLAorCSdmdW5jdGlvbiBpcyBwcmVzZW50IGluIGR1bXAnKTsKKworIyBObyBHUkFOVCBzdGF0 ZW1lbnQgc2hvdWxkIHJlZmVyZW5jZSBhIGJhcmUgbnVtZXJpYyBPSUQgYXMgYSByb2xlIG5hbWUu Cit1bmxpa2UoJGR1bXAsIHFyL0dSQU5UXGIuKlxiVE9ccysiWzAtOV0rIi8sCisJJ25vIEdSQU5U IHdpdGggbnVtZXJpYyBPSUQgYXMgcm9sZSBuYW1lJyk7CisKKyMgTm8gR1JBTlQgYXQgYWxsIGZv ciB0ZXN0X2Z1bmM6IGFsbCBpbml0cHJpdnMgZW50cmllcyB3ZXJlIGRhbmdsaW5nIGFuZAorIyBw cm9hY2wgaXMgTlVMTCwgc28gdGhlcmUgaXMgbm90aGluZyB0byBlbWl0LgordW5saWtlKCRkdW1w LCBxci9HUkFOVFxiLipcYnRlc3RfZnVuYy8sCisJJ25vIEdSQU5UIGZvciB0ZXN0X2Z1bmMgd2hl biBhbGwgaW5pdHByaXZzIGVudHJpZXMgYXJlIGRhbmdsaW5nJyk7CisKK2RvbmVfdGVzdGluZygp OwotLSAKMi41MC4xIChBcHBsZSBHaXQtMTU1KQoK --000000000000dd432106549669d4--