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.94.2) (envelope-from ) id 1qpTea-005sXH-6p for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Oct 2023 13:17:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qpTeW-006EAo-EK for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Oct 2023 13:17:01 +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.94.2) (envelope-from ) id 1qpTeW-006EAg-24 for pgsql-bugs@lists.postgresql.org; Sun, 08 Oct 2023 13:17:01 +0000 Received: from ma03-relay.lansolnet.com ([176.95.46.36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qpTeU-000vOL-7U for pgsql-bugs@lists.postgresql.org; Sun, 08 Oct 2023 13:17:00 +0000 Received: from unknown ([192.168.8.231]) by ma03-relay.lansolnet.com; Sun, 08 Oct 2023 15:16:55 +0200 Received: from MBX200E.cloud4partner.com (192.168.8.234) by MBX200B.cloud4partner.com (192.168.8.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sun, 8 Oct 2023 15:16:52 +0200 Received: from MBX200E.cloud4partner.com ([fe80::881b:2a52:f04f:d634]) by MBX200E.cloud4partner.com ([fe80::881b:2a52:f04f:d634%13]) with mapi id 15.01.0669.032; Sun, 8 Oct 2023 15:16:52 +0200 From: Hans Buschmann To: Tom Lane , "David G. Johnston" CC: "pgsql-bugs@lists.postgresql.org" Subject: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx Thread-Topic: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx Thread-Index: AQHZ95SMlAcyyDepIUuM64bIjWMVCrA7LBuAgAAf8QCABJEsgA== Date: Sun, 8 Oct 2023 13:16:52 +0000 Message-ID: <9fdfed847859435e8641e613198be9e3@nidsa.net> References: <18147-6fc796538913ee88@postgresql.org> ,<2796464.1696525626@sss.pgh.pa.us> In-Reply-To: <2796464.1696525626@sss.pgh.pa.us> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.8.240] Content-Type: multipart/mixed; boundary="_004_9fdfed847859435e8641e613198be9e3nidsanet_" MIME-Version: 1.0 X-cloud-security-sender: buschmann@nidsa.net X-cloud-security-recipient: pgsql-bugs@lists.postgresql.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on ma03-relay.lansolnet.com with 03CC11985C89 X-cloud-security-connect: unknown[192.168.8.231], TLS=1, IP=192.168.8.231 X-cloud-security: scantime:.6378 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_004_9fdfed847859435e8641e613198be9e3nidsanet_ Content-Type: multipart/alternative; boundary="_000_9fdfed847859435e8641e613198be9e3nidsanet_" --_000_9fdfed847859435e8641e613198be9e3nidsanet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, For your reference I include a simple dump of a test case database, which e= xecutes the queries but does NOT reproduce the error. This case seems much more complicated then I thought on first view. The problem arose on the production database after it has been dumped/resto= re from pg15.4 to pg16.0 and was observed on failing queries from the appli= cation. Many tables in production have an inherited table called xxxtable_archiv, w= hich contains elder data and are not often updated by the application. So t= he error is seldom. The normal access is only through the main table like: explain analyze -- explain analyze verbose -- explain -- select * from ( --= select count(*) from ( -- select length(sel) from ( with qp_netto as ( select 77812::int as id_of , 1.000000::numeric(8,6) as fac_to_us , 6.9318647425014148::numeric(8,3) as prfac_netto_1, 0.0::numeric(8,3) as prfac_netto_2, 1.000000::numeric(8,6) as our_to_us , 6.88795000000000000000::numeric(8,3) as prour_netto_1, 0.0::numeric(8,3) as prour_netto_2 ) -- select * from qp_netto; update or_followup set of_pr1_fac_netto=3Dcoalesce(prfac_netto_1,0.0) ,of_pr1_fac_netusd=3Dcoalesce(prfac_netto_1*fac_to_us,0.0) ,of_pr2_fac_netto=3Dcoalesce(prfac_netto_2,0.0) ,of_pr2_fac_netusd=3Dcoalesce(prfac_netto_2*fac_to_us,0.0) ,of_pr1_our_netto=3Dcoalesce(prour_netto_1,0.0) ,of_pr1_our_netusd=3Dcoalesce(prour_netto_1*our_to_us,0.0) ,of_pr2_our_netto=3Dcoalesce(prour_netto_2,0.0) ,of_pr2_our_netusd=3Dcoalesce(prour_netto_2*our_to_us,0.0) from qp_netto where or_followup.id_of=3Dqp_netto.id_of and or_followup.of_season=3D35 ; xxxdb-# ; FEHLER: invalid perminfoindex 0 in RTE with relid 17034 (relid 17034=3Dor_followup_archiv) which failed repeatedly on production and a local copy (pg_dump/restore). When you try to access the xxx_archiv table directly like : explain analyze -- explain analyze verbose -- explain -- select * from ( --= select count(*) from ( -- select length(sel) from ( with qp_netto as ( select 77812::int as id_of , 1.000000::numeric(8,6) as fac_to_us , 6.9318647425014148::numeric(8,3) as prfac_netto_1, 0.0::numeric(8,3) as prfac_netto_2, 1.000000::numeric(8,6) as our_to_us , 6.88795000000000000000::numeric(8,3) as prour_netto_1, 0.0::numeric(8,3) as prour_netto_2 ) -- select * from qp_netto; update or_followup_archiv set of_pr1_fac_netto=3Dcoalesce(prfac_netto_1,0.0) ,of_pr1_fac_netusd=3Dcoalesce(prfac_netto_1*fac_to_us,0.0) ,of_pr2_fac_netto=3Dcoalesce(prfac_netto_2,0.0) ,of_pr2_fac_netusd=3Dcoalesce(prfac_netto_2*fac_to_us,0.0) ,of_pr1_our_netto=3Dcoalesce(prour_netto_1,0.0) ,of_pr1_our_netusd=3Dcoalesce(prour_netto_1*our_to_us,0.0) ,of_pr2_our_netto=3Dcoalesce(prour_netto_2,0.0) ,of_pr2_our_netusd=3Dcoalesce(prour_netto_2*our_to_us,0.0) from qp_netto where or_followup_archiv.id_of=3Dqp_netto.id_of and or_followup_archiv.of_season=3D35 ; this query succeeds and shows the execution plan! BUT: Once this query of the archiv table is run (and updated 1 record) the origi= nal query through the main table (without archiv) also succeeds! So when one update is run successfully, the error is not reproducable any m= ore! This behavior is preserved through pg_dump/pg_restore of the whole databsas= e for both succes and failure case. I have no clue what difference in the dump file would trigger this: On comp= arison of an sql dump only the updated row is moved at the end of the copy,= nothing else changed. Unfortunatly the provided errdb_noerr does not show the error (due to manua= lly creation steps perhaps). Hans Buschmann --_000_9fdfed847859435e8641e613198be9e3nidsanet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,


For your reference I include a simple dump of a test case database, whic= h executes the queries but does NOT reproduce the error.


This case seems much more complicated then I = thought on first view.

The problem arose on the production database after= it has been dumped/restore from pg15.4 to pg16.0 and was observed on faili= ng queries from the application.

Many tables in production have an inherited table = called xxxtable_archiv, which contains elder data and are not often updated= by the application. So the error is seldom.

The normal access is only through the main table l= ike:

explain analyze -- explain analyze verbose -- explain -- select * from= ( -- select count(*) from ( -- select length(sel) from (
with qp_netto as (
select 
77812::int                &nbs= p;             as id_of      &= nbsp; ,
1.000000::numeric(8,6)             =     as fac_to_us    ,
6.9318647425014148::numeric(8,3)        as prfac_n= etto_1,
0.0::numeric(8,3)              &nbs= p;        as prfac_netto_2,
1.000000::numeric(8,6)             =     as our_to_us    ,
6.88795000000000000000::numeric(8,3)    as prour_netto_1,
0.0::numeric(8,3)              &nbs= p;        as prour_netto_2
)
-- select * from qp_netto;
update  or_followup set
 of_pr1_fac_netto=3Dcoalesce(prfac_netto_1,0.0)
,of_pr1_fac_netusd=3Dcoalesce(prfac_netto_1*fac_to_us,0.0)
,of_pr2_fac_netto=3Dcoalesce(prfac_netto_2,0.0)
,of_pr2_fac_netusd=3Dcoalesce(prfac_netto_2*fac_to_us,0.0)
,of_pr1_our_netto=3Dcoalesce(prour_netto_1,0.0)
,of_pr1_our_netusd=3Dcoalesce(prour_netto_1*our_to_us,0.0)
,of_pr2_our_netto=3Dcoalesce(prour_netto_2,0.0)
,of_pr2_our_netusd=3Dcoalesce(prour_netto_2*our_to_us,0.0)
from qp_netto
where
or_followup.id_of=3Dqp_netto.id_of
and or_followup.of_season=3D35
;

xxxdb-# ;
FEHLER:  invalid perminfoindex 0 in RTE with relid 17034

(relid 17034=3Dor_followup_archiv)

which failed repeatedly on production and a local copy (pg_dump/restor= e).


When you try to access the xxx_archiv table directly like :

explain analyze -- explain analyze verbose -- explain -- select * from= ( -- select count(*) from ( -- select length(sel) from (
with qp_netto as (
select 
77812::int                &nbs= p;             as id_of      &= nbsp; ,
1.000000::numeric(8,6)             =     as fac_to_us    ,
6.9318647425014148::numeric(8,3)        as prfac_n= etto_1,
0.0::numeric(8,3)              &nbs= p;        as prfac_netto_2,
1.000000::numeric(8,6)             =     as our_to_us    ,
6.88795000000000000000::numeric(8,3)    as prour_netto_1,
0.0::numeric(8,3)              &nbs= p;        as prour_netto_2
)
-- select * from qp_netto;
update  or_followup_archiv set
 of_pr1_fac_netto=3Dcoalesce(prfac_netto_1,0.0)
,of_pr1_fac_netusd=3Dcoalesce(prfac_netto_1*fac_to_us,0.0)
,of_pr2_fac_netto=3Dcoalesce(prfac_netto_2,0.0)
,of_pr2_fac_netusd=3Dcoalesce(prfac_netto_2*fac_to_us,0.0)
,of_pr1_our_netto=3Dcoalesce(prour_netto_1,0.0)
,of_pr1_our_netusd=3Dcoalesce(prour_netto_1*our_to_us,0.0)
,of_pr2_our_netto=3Dcoalesce(prour_netto_2,0.0)
,of_pr2_our_netusd=3Dcoalesce(prour_netto_2*our_to_us,0.0)
from qp_netto
where
or_followup_archiv.id_of=3Dqp_netto.id_of
and or_followup_archiv.of_season=3D35
;

this query succeeds and shows the execution plan!

BUT:

Once this query of the archiv table is run (and updated 1 record) the = original query through the main table (without archiv) also succeeds!
So when one update is run successfully, the error is not reproducable = any more!

This behavior is preserved through pg_dump/pg_restore of the whole dat= absase for both succes and failure case.

I have no clue what difference in the dump file would trigger this: On= comparison of an sql dump only the updated row is moved at the end of= the copy, nothing else changed.


Unfortunatly the provided errdb_noerr does not show the error (due to = manually creation steps perhaps).

Hans Buschmann


--_000_9fdfed847859435e8641e613198be9e3nidsanet_-- --_004_9fdfed847859435e8641e613198be9e3nidsanet_ Content-Type: application/octet-stream; name="errdb_noerr_231008.sql" Content-Description: errdb_noerr_231008.sql Content-Disposition: attachment; filename="errdb_noerr_231008.sql"; size=4443; creation-date="Sun, 08 Oct 2023 12:54:19 GMT"; modification-date="Sun, 08 Oct 2023 12:54:19 GMT" Content-Transfer-Encoding: base64 LS0KLS0gUG9zdGdyZVNRTCBkYXRhYmFzZSBkdW1wCi0tCgotLSBEdW1wZWQgZnJvbSBkYXRhYmFz ZSB2ZXJzaW9uIDE2LjAKLS0gRHVtcGVkIGJ5IHBnX2R1bXAgdmVyc2lvbiAxNi4wCgpTRVQgc3Rh dGVtZW50X3RpbWVvdXQgPSAwOwpTRVQgbG9ja190aW1lb3V0ID0gMDsKU0VUIGlkbGVfaW5fdHJh bnNhY3Rpb25fc2Vzc2lvbl90aW1lb3V0ID0gMDsKU0VUIGNsaWVudF9lbmNvZGluZyA9ICdVVEY4 JzsKU0VUIHN0YW5kYXJkX2NvbmZvcm1pbmdfc3RyaW5ncyA9IG9uOwpTRUxFQ1QgcGdfY2F0YWxv Zy5zZXRfY29uZmlnKCdzZWFyY2hfcGF0aCcsICcnLCBmYWxzZSk7ClNFVCBjaGVja19mdW5jdGlv bl9ib2RpZXMgPSBmYWxzZTsKU0VUIHhtbG9wdGlvbiA9IGNvbnRlbnQ7ClNFVCBjbGllbnRfbWlu X21lc3NhZ2VzID0gd2FybmluZzsKU0VUIHJvd19zZWN1cml0eSA9IG9mZjsKCi0tCi0tIE5hbWU6 IGFyY2hpdjsgVHlwZTogU0NIRU1BOyBTY2hlbWE6IC07IE93bmVyOiBwb3N0Z3JlcwotLQoKQ1JF QVRFIFNDSEVNQSBhcmNoaXY7CgoKQUxURVIgU0NIRU1BIGFyY2hpdiBPV05FUiBUTyBwb3N0Z3Jl czsKCi0tCi0tIE5hbWU6IGZuX29yX2ZvbGxvd3VwX2luc2VydCgpOyBUeXBlOiBGVU5DVElPTjsg U2NoZW1hOiBwdWJsaWM7IE93bmVyOiBwb3N0Z3JlcwotLQoKQ1JFQVRFIEZVTkNUSU9OIHB1Ymxp Yy5mbl9vcl9mb2xsb3d1cF9pbnNlcnQoKSBSRVRVUk5TIHRyaWdnZXIKICAgIExBTkdVQUdFIHBs cGdzcWwKICAgIEFTICQkCmJlZ2luCmluc2VydCBpbnRvIG9yX2ZvbGxvd3VwX2FyY2hpdiB2YWx1 ZXMgKE5FVy4qKTsKcmV0dXJuIE5VTEw7CmVuZDsKJCQ7CgoKQUxURVIgRlVOQ1RJT04gcHVibGlj LmZuX29yX2ZvbGxvd3VwX2luc2VydCgpIE9XTkVSIFRPIHBvc3RncmVzOwoKU0VUIGRlZmF1bHRf dGFibGVzcGFjZSA9ICcnOwoKU0VUIGRlZmF1bHRfdGFibGVfYWNjZXNzX21ldGhvZCA9IGhlYXA7 CgotLQotLSBOYW1lOiBvcl9mb2xsb3d1cDsgVHlwZTogVEFCTEU7IFNjaGVtYTogcHVibGljOyBP d25lcjogcG9zdGdyZXMKLS0KCkNSRUFURSBUQUJMRSBwdWJsaWMub3JfZm9sbG93dXAgKAogICAg aWRfb2YgaW50ZWdlciBOT1QgTlVMTCwKICAgIG9mX3NlYXNvbiBzbWFsbGludCBOT1QgTlVMTCwK ICAgIG9mX3ByMV9mYWNfbmV0dG8gbnVtZXJpYyg4LDIpIERFRkFVTFQgMC4wMCwKICAgIG9mX3By MV9mYWNfbmV0dXNkIG51bWVyaWMoOCwyKSBERUZBVUxUIDAuMDAsCiAgICBvZl9wcjJfZmFjX25l dHRvIG51bWVyaWMoOCwyKSBERUZBVUxUIDAsCiAgICBvZl9wcjJfZmFjX25ldHVzZCBudW1lcmlj KDgsMikgREVGQVVMVCAwLAogICAgb2ZfcHIxX291cl9uZXR0byBudW1lcmljKDgsNCkgREVGQVVM VCAwLjAwLAogICAgb2ZfcHIxX291cl9uZXR1c2QgbnVtZXJpYyg4LDQpIERFRkFVTFQgMC4wMCwK ICAgIG9mX3ByMl9vdXJfbmV0dG8gbnVtZXJpYyg4LDQpIERFRkFVTFQgMCwKICAgIG9mX3ByMl9v dXJfbmV0dXNkIG51bWVyaWMoOCw0KSBERUZBVUxUIDAsCiAgICBDT05TVFJBSU5UIGNrX29mX25l dyBDSEVDSyAoKG9mX3NlYXNvbiA+PSAzNikpIE5PIElOSEVSSVQKKQpXSVRIIChmaWxsZmFjdG9y PSc2MCcpOwoKCkFMVEVSIFRBQkxFIHB1YmxpYy5vcl9mb2xsb3d1cCBPV05FUiBUTyBwb3N0Z3Jl czsKCi0tCi0tIE5hbWU6IG9yX2ZvbGxvd3VwX2FyY2hpdjsgVHlwZTogVEFCTEU7IFNjaGVtYTog YXJjaGl2OyBPd25lcjogcG9zdGdyZXMKLS0KCkNSRUFURSBUQUJMRSBhcmNoaXYub3JfZm9sbG93 dXBfYXJjaGl2ICgKICAgIENPTlNUUkFJTlQgY2tfb2Zfb2xkIENIRUNLICgob2Zfc2Vhc29uIDwg MzYpKSBOTyBJTkhFUklUCikKSU5IRVJJVFMgKHB1YmxpYy5vcl9mb2xsb3d1cCk7CgoKQUxURVIg VEFCTEUgYXJjaGl2Lm9yX2ZvbGxvd3VwX2FyY2hpdiBPV05FUiBUTyBwb3N0Z3JlczsKCi0tCi0t IE5hbWU6IG9yX2ZvbGxvd3VwX2FyY2hpdiBvZl9wcjFfZmFjX25ldHRvOyBUeXBlOiBERUZBVUxU OyBTY2hlbWE6IGFyY2hpdjsgT3duZXI6IHBvc3RncmVzCi0tCgpBTFRFUiBUQUJMRSBPTkxZIGFy Y2hpdi5vcl9mb2xsb3d1cF9hcmNoaXYgQUxURVIgQ09MVU1OIG9mX3ByMV9mYWNfbmV0dG8gU0VU IERFRkFVTFQgMC4wMDsKCgotLQotLSBOYW1lOiBvcl9mb2xsb3d1cF9hcmNoaXYgb2ZfcHIxX2Zh Y19uZXR1c2Q7IFR5cGU6IERFRkFVTFQ7IFNjaGVtYTogYXJjaGl2OyBPd25lcjogcG9zdGdyZXMK LS0KCkFMVEVSIFRBQkxFIE9OTFkgYXJjaGl2Lm9yX2ZvbGxvd3VwX2FyY2hpdiBBTFRFUiBDT0xV TU4gb2ZfcHIxX2ZhY19uZXR1c2QgU0VUIERFRkFVTFQgMC4wMDsKCgotLQotLSBOYW1lOiBvcl9m b2xsb3d1cF9hcmNoaXYgb2ZfcHIyX2ZhY19uZXR0bzsgVHlwZTogREVGQVVMVDsgU2NoZW1hOiBh cmNoaXY7IE93bmVyOiBwb3N0Z3JlcwotLQoKQUxURVIgVEFCTEUgT05MWSBhcmNoaXYub3JfZm9s bG93dXBfYXJjaGl2IEFMVEVSIENPTFVNTiBvZl9wcjJfZmFjX25ldHRvIFNFVCBERUZBVUxUIDA7 CgoKLS0KLS0gTmFtZTogb3JfZm9sbG93dXBfYXJjaGl2IG9mX3ByMl9mYWNfbmV0dXNkOyBUeXBl OiBERUZBVUxUOyBTY2hlbWE6IGFyY2hpdjsgT3duZXI6IHBvc3RncmVzCi0tCgpBTFRFUiBUQUJM RSBPTkxZIGFyY2hpdi5vcl9mb2xsb3d1cF9hcmNoaXYgQUxURVIgQ09MVU1OIG9mX3ByMl9mYWNf bmV0dXNkIFNFVCBERUZBVUxUIDA7CgoKLS0KLS0gTmFtZTogb3JfZm9sbG93dXBfYXJjaGl2IG9m X3ByMV9vdXJfbmV0dG87IFR5cGU6IERFRkFVTFQ7IFNjaGVtYTogYXJjaGl2OyBPd25lcjogcG9z dGdyZXMKLS0KCkFMVEVSIFRBQkxFIE9OTFkgYXJjaGl2Lm9yX2ZvbGxvd3VwX2FyY2hpdiBBTFRF UiBDT0xVTU4gb2ZfcHIxX291cl9uZXR0byBTRVQgREVGQVVMVCAwLjAwOwoKCi0tCi0tIE5hbWU6 IG9yX2ZvbGxvd3VwX2FyY2hpdiBvZl9wcjFfb3VyX25ldHVzZDsgVHlwZTogREVGQVVMVDsgU2No ZW1hOiBhcmNoaXY7IE93bmVyOiBwb3N0Z3JlcwotLQoKQUxURVIgVEFCTEUgT05MWSBhcmNoaXYu b3JfZm9sbG93dXBfYXJjaGl2IEFMVEVSIENPTFVNTiBvZl9wcjFfb3VyX25ldHVzZCBTRVQgREVG QVVMVCAwLjAwOwoKCi0tCi0tIE5hbWU6IG9yX2ZvbGxvd3VwX2FyY2hpdiBvZl9wcjJfb3VyX25l dHRvOyBUeXBlOiBERUZBVUxUOyBTY2hlbWE6IGFyY2hpdjsgT3duZXI6IHBvc3RncmVzCi0tCgpB TFRFUiBUQUJMRSBPTkxZIGFyY2hpdi5vcl9mb2xsb3d1cF9hcmNoaXYgQUxURVIgQ09MVU1OIG9m X3ByMl9vdXJfbmV0dG8gU0VUIERFRkFVTFQgMDsKCgotLQotLSBOYW1lOiBvcl9mb2xsb3d1cF9h cmNoaXYgb2ZfcHIyX291cl9uZXR1c2Q7IFR5cGU6IERFRkFVTFQ7IFNjaGVtYTogYXJjaGl2OyBP d25lcjogcG9zdGdyZXMKLS0KCkFMVEVSIFRBQkxFIE9OTFkgYXJjaGl2Lm9yX2ZvbGxvd3VwX2Fy Y2hpdiBBTFRFUiBDT0xVTU4gb2ZfcHIyX291cl9uZXR1c2QgU0VUIERFRkFVTFQgMDsKCgotLQot LSBEYXRhIGZvciBOYW1lOiBvcl9mb2xsb3d1cF9hcmNoaXY7IFR5cGU6IFRBQkxFIERBVEE7IFNj aGVtYTogYXJjaGl2OyBPd25lcjogcG9zdGdyZXMKLS0KCkNPUFkgYXJjaGl2Lm9yX2ZvbGxvd3Vw X2FyY2hpdiAoaWRfb2YsIG9mX3NlYXNvbiwgb2ZfcHIxX2ZhY19uZXR0bywgb2ZfcHIxX2ZhY19u ZXR1c2QsIG9mX3ByMl9mYWNfbmV0dG8sIG9mX3ByMl9mYWNfbmV0dXNkLCBvZl9wcjFfb3VyX25l dHRvLCBvZl9wcjFfb3VyX25ldHVzZCwgb2ZfcHIyX291cl9uZXR0bywgb2ZfcHIyX291cl9uZXR1 c2QpIEZST00gc3RkaW47Cjc3ODEyCTM1CTYuOTMJNi45MwkwLjAwCTAuMDAJNi44ODgwCTYuODg4 MAkwLjAwMDAJMC4wMDAwClwuCgoKLS0KLS0gRGF0YSBmb3IgTmFtZTogb3JfZm9sbG93dXA7IFR5 cGU6IFRBQkxFIERBVEE7IFNjaGVtYTogcHVibGljOyBPd25lcjogcG9zdGdyZXMKLS0KCkNPUFkg cHVibGljLm9yX2ZvbGxvd3VwIChpZF9vZiwgb2Zfc2Vhc29uLCBvZl9wcjFfZmFjX25ldHRvLCBv Zl9wcjFfZmFjX25ldHVzZCwgb2ZfcHIyX2ZhY19uZXR0bywgb2ZfcHIyX2ZhY19uZXR1c2QsIG9m X3ByMV9vdXJfbmV0dG8sIG9mX3ByMV9vdXJfbmV0dXNkLCBvZl9wcjJfb3VyX25ldHRvLCBvZl9w cjJfb3VyX25ldHVzZCkgRlJPTSBzdGRpbjsKXC4KCgotLQotLSBOYW1lOiBvcl9mb2xsb3d1cCB0 cl9vcl9mb2xsb3d1cF9pbnNlcnQ7IFR5cGU6IFRSSUdHRVI7IFNjaGVtYTogcHVibGljOyBPd25l cjogcG9zdGdyZXMKLS0KCkNSRUFURSBUUklHR0VSIHRyX29yX2ZvbGxvd3VwX2luc2VydCBCRUZP UkUgSU5TRVJUIE9OIHB1YmxpYy5vcl9mb2xsb3d1cCBGT1IgRUFDSCBST1cgV0hFTiAoKG5ldy5v Zl9zZWFzb24gPCAzNikpIEVYRUNVVEUgRlVOQ1RJT04gcHVibGljLmZuX29yX2ZvbGxvd3VwX2lu c2VydCgpOwoKCi0tCi0tIFBvc3RncmVTUUwgZGF0YWJhc2UgZHVtcCBjb21wbGV0ZQotLQoK --_004_9fdfed847859435e8641e613198be9e3nidsanet_--