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 1vkxuh-0057oU-2O for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 05:16:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vkxug-00HS2h-2V for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jan 2026 05:16:23 +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 1vkxug-00HS2Y-0j for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 05:16:22 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vkxud-002gKS-0M for pgsql-hackers@lists.postgresql.org; Wed, 28 Jan 2026 05:16:21 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-35305538592so5686115a91.0 for ; Tue, 27 Jan 2026 21:16:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769577379; cv=none; d=google.com; s=arc-20240605; b=D5BeGKmGYMboQ9lUY9kCv3bt1pst5nu0v2MJIFvTuw+Y0WjKkTvbzYcbJixS37hUOl KDo/uADWSmJ2RJIVn2FMmyPqmt+qblXCykHqRU/jKA2UDdL4rgEfEesLfOiiK4maB2No ZnTxIBvVigs2bDoCoyEQtTEYMZEB25fruJngSKq5TNrnNcMmn128m5HE3btHFQYW9jmT hLkVgss/a0LO8jZTpRZSIAcgEtZsblw2xjgBGqKfWwbf4l3ra54sZZbd/EXuW3/xRsGW xZOCpnHE3DxRBBPOPLfg4Co5JIQfDF1DaRoeRsm7ssW2HEHXHT8fwu+EOvznHF5TbTJe /Qcg== 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=4YAesQXyg0Glj7n/b1Rrn0h2uWxcA9mcFLgAqOOMTeY=; fh=m3thyvHX5aF827P0nKNBXvaA5zLQBnJUgMmS8AUK1Q8=; b=YWh5CdcwwVkqVRDpIlpvG1gnxN1ivURNcTH9wcN0vYDtwHB5CR6OzH60PFuhKOfVKH Yis6NztvEwta4RrolRCpj4Zl6TAVA26+j5k2JaCKyreRTX562ZtSXyLpCnJxlMCQRO5Z bh2ftTSbMXH27x9kQCSA8seWnz4yh/iZdkg0FYAoVaKF1KKldDKjMwqtJo0Nr9eTSI/U So5vvSwyxoP1dal3Cv5xa/5m33yCg6QGhNEOdokkv594tutYs/PPPXESSlWRw/gg9LMr 2C36hzxuZyYyviZxsRZy2Hjt2bn71tHha4TZX7D4gpUJKl7FsEI8E+fnHUTfI19IqS9m WIyQ==; 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=1769577379; x=1770182179; 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=4YAesQXyg0Glj7n/b1Rrn0h2uWxcA9mcFLgAqOOMTeY=; b=ZwrSUv0J4VuEjp/mCIaD7nhNJzYbF9mW085Dz2LgVhBRucgICYkxQRYvtZ5dwRs1b5 uaV9mMUvHnZ6l9f2bZJ0OCI1I6QVL20ciNdZ1rzx1pnEcI2BNESmk3HiCM8m5E6ARLJi EW6dOdKnP+WrpK4wL6lICE1ocGVa1gDlWSiGv7uQvm5chbhbZyKxyhGmz+Q2IEnMndXI gaSWzgpQIMZ0VT3YocrO3kkvddwycr1b8+wBEVkhJxFom/pJkpE6DhahgWaVNboMe1ht c7HEuVqup3C/1Uk/SH9Hjb1R4DQYh5RwJFJmZrSFkxyTln74c6CflmvAzg0dNAB2rW6J /gHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769577379; x=1770182179; 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=4YAesQXyg0Glj7n/b1Rrn0h2uWxcA9mcFLgAqOOMTeY=; b=Z4LNBw+GRg1yoqFmWvWbf5nB2YKbnaJl0LtuNvmyctxGL1w/tA4eF0kJIRHB93nHCK jaXOLOSTcrU+ytSuKMHZQy2sBBQDmo8au6RjR1s5UqUsZ/p+OvDpZR9C6QxYTcKH+Lq0 WBKRyBeovxS+S4qgzCN0LfVhvMqZBxMZd6cB3QVN6M6ooEFtMRs4Bz1VwN3hlr4boS5w X2mMjIQy/EQP5WO5rvLlWLVr6WFswst/C8khfOIguRFoPZv377sgq0BDJLF1lcIWLSCP ie3xWX6NwFGl2rDUIPggSrOq/vtmCSbGAvy8AWinGSYctImf4r9/viUEznV1G8c3RTcQ lFtg== X-Forwarded-Encrypted: i=1; AJvYcCWwRkdbRUd58mAh69VHrCPj2K9Q7/2Xg9oDNw+N9mWHhAeajFP1mQhxvFCkH1B3Gz/JsNbmX1rcHna+kveO@lists.postgresql.org X-Gm-Message-State: AOJu0YywDWkKw5q3/SrDtz/IozaT1Y/tLCGXW6FQfVU//uYv/Tmt5RVc xiXDea9HGOp0T893gDEqxhvltozm7rDmRIJLD1gQC5NHp8aNGyf3NcXy+wemVieR/S5/df+s34Y iHHUjgHevjh4YeyX9kPT+Vuc/wehGPKM= X-Gm-Gg: AZuq6aLLQcJ7nxKtfpsJhhnBDnS/n1Xp/gjAzFP3UISY2Y1AA8eiKU+2qraigm/SHMB yQqBvATl/VMTCfpN4TCreqQaqyK+I58ZML74UkkL/mOPfxem0pEi5FPPVwmOvfDi4iM6QT5Okj5 G6V9eaRymWbYUa11uDQjUmQ/b0e6FQEs0CP5sXzxaigf/0mHMAvxypbjWGsJ3JhC7hWZZv4vw9m kCmUK3wdCr9LZgl/4BOiuF7sS5uRceMKN+lg5JgaVaAE58g0X+JQM2LTvTCeHZ4n8BVuQyPmEgJ bh90VDt7giochgOLoYrfnl0pKoSFc3IlOd2k6J3pnA== X-Received: by 2002:a17:90b:350e:b0:341:8ac7:39b7 with SMTP id 98e67ed59e1d1-353fed79217mr3642684a91.25.1769577378638; Tue, 27 Jan 2026 21:16:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 28 Jan 2026 10:46:07 +0530 X-Gm-Features: AZwV_QjHH1Q8NEESddhaR7HyZQcTqefsN0CUujjl6eMzGj_vLlBgskHSNUN780Y Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: Dilip Kumar , Amit Kapila , Shlok Kyal , Peter Smith , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: multipart/mixed; boundary="0000000000000e82cb06496bd7e2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000e82cb06496bd7e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2026 at 8:25=E2=80=AFPM vignesh C wro= te: > > On Fri, 23 Jan 2026 at 18:41, vignesh C wrote: > > > > On Wed, 21 Jan 2026 at 11:35, Dilip Kumar wrote= : > > > > > > On Mon, Jan 19, 2026 at 3:08=E2=80=AFPM shveta malik wrote: > > > > > > > > Approaches for Supporting EXCEPT in Partitioned Tables > > > > -------------------------------------------------------------------= ----- > > > > > > > > In an offline discussion with Peter Smith, Amit, and Shlok, we > > > > identified several approaches for supporting EXCEPT with partitione= d > > > > tables and their partitions. I=E2=80=99d like to hear others=E2=80= =99 opinions on > > > > these approaches. > > > > > > > > Consider the following partition hierarchy: > > > > tab_root > > > > =E2=94=9C=E2=94=80 tab_part_1 > > > > =E2=94=82 =E2=94=9C=E2=94=80 tab_part_1_p1 > > > > =E2=94=82 =E2=94=94=E2=94=80 tab_part_1_p2 > > > > =E2=94=94=E2=94=80 tab_part_2 > > > > =E2=94=9C=E2=94=80 tab_part_2_p1 > > > > =E2=94=94=E2=94=80 tab_part_2_p2 > > > > > > > > > > > > Approach 1: > > > > --------------------------------- > > > > If we exclude a table, then the data in that table and all of its > > > > partitions (i.e., the entire subtree under that table) should not b= e > > > > replicated. > > > > > > > > For example EXCEPT (tab_part_1) skips replication of tab_part_1 and > > > > all of its partitions. > > > > > > > > This behaviour remains the same with or without > > > > publish_via_partition_root. The publish_via_partition_root flag onl= y > > > > affects publish_via_relid, i.e., the relation through which data is > > > > published. > > > > > > > > This approach involves certain implementation challenges. For brevi= ty, > > > > these are documented in the attached 'Approach1_challenges' documen= t. > > > > > > > > Approach 2: > > > > --------------------------------------------------- > > > > Assign meaning to ONLY and '*' for partition tables in the EXCEPT > > > > list. In HEAD, ONLY and '*' do not have any meaning for partitioned > > > > tables or partitions, and these keywords are currently ignored. > > > > > > > > Examples: > > > > 1. EXCEPT (ONLY tab_part_1) skips replication of only the table > > > > tab_part_1. Changes for tab_root, tab_part_1_p1, and tab_part_1_p2 = are > > > > still replicated. > > > > > > > > ii. EXCEPT (tab_part_1*) skips replication of tables tab_part_1, > > > > tab_part_1_p1, and tab_part_1_p2 > > > > > > > > The challenges described in Approach 1, particularly around tablesy= nc > > > > handling and COPY behaviour, would still need to be addressed under > > > > this approach as well. ONLY or '*' with partitioned tables is not > > > > supported in HEAD, supporting it specifically for ALL TABLES EXCEPT > > > > may introduce additional confusion for users. > > > > > > > > Approach 3: > > > > ---------------- > > > > Do not allow partitions to be specified in the EXCEPT clause. > > > > > > > > Only EXCEPT (tab_root) is supported, which excludes tab_root and al= l > > > > of its partitions. Specifying EXCEPT (tab_part_1) or EXCEPT > > > > (tab_part_1_p1) will result in an error. > > > > > > > > ~~ > > > > > > > > While Approach 1 and Approach 2 offer more flexibility to the user > > > > compared to Approach 3, they also introduce additional design > > > > complexity which does not seem simpler to address. > > > > > > Thanks for explaining this, overall I like the Approach 1, and I also > > > see the problem when publish via root is given in that case COPY FROM > > > is executed on the root and it would be hard to exclude specific > > > partitions. > > > > Regarding the above issue which is also mentioned in > > Approach1_challenges at [1]: > > When a publication is created with publish_via_partition_root =3D true > > and a specific partition(tab_part_1_1) is excluded, the expected > > behavior is that changes from non-excluded partitions (for example, > > tab_part_2 and tab_part_1_2 and their descendants) are replicated, > > while changes from the excluded partition (tab_part_1_1 and its > > subtree) are not. > > tab_root > > =E2=94=9C=E2=94=80=E2=94=80 tab_part_1 > > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_1=E2=80=83=E2=80=83= =E2=80=83=E2=80=83=E2=80=83=E2=80=83=E2=80=83=E2=80=83(except) > > =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_1_1 > > =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_par= t_1_1_1_1 > > =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_1_2 > > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_2 > > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_2_1 > > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_2_2 > > =E2=94=94=E2=94=80=E2=94=80 tab_part_2 > > > > In this situation, replication cannot be performed purely via the > > partition root (tab_root), because doing so would implicitly include > > data from the excluded child partitions. > > > > To address this, the publication creation should explicitly record the > > excluded partition(tab_part_1_1) in pg_publication_rel with an > > excluded =3D true flag. The publish_via_partition_root setting remains > > stored at the publication level, as it is today. With > > publish_via_partition_root =3D true, the publisher=E2=80=93subscriber m= apping is > > not partition-to-partition. Instead, all eligible data is mapped to > > the subscriber=E2=80=99s partition root. Therefore, > > pg_get_publication_tables() should return only the top-level root > > table (tab_root) to the subscriber for table synchronization. During > > initial table sync, when the tablesync worker prepares the COPY > > command, it can query the publisher to determine the effective set of > > tables that belong to the publication after applying the exclusion > > rules. Based on this resolved table list, the tablesync worker can > > construct a COPY query that unions data only from the non-excluded > > partitions, for example: > > COPY ( > > SELECT * FROM tab_part_1_2_1 > > UNION ALL > > SELECT * FROM tab_part_1_2_2 > > UNION ALL > > SELECT * FROM tab_part_2 > > ) > > > > This ensures that only non-excluded data is copied and applied to > > tab_root on the subscriber, while preserving the semantics of > > publish_via_partition_root =3D true. I agree with the suggested changes in tablesync. It will be good if we can add these details in the commit-msg section of the patch. Also please mention how increment replication is impacted (or supposed to work) with Approach1. > Here is a patch which has the changes to handle the same. > Thank You for the patch. 1) There are certain parts of Approach 3 still present in Approach 1, as an example: 1a) + For partitioned tables, only the root partitioned table may be speci= fied + in EXCEPT TABLE. 1b) + /* + * Only the topmost ancestor of a partitioned table can be specified + * in EXCEPT TABLES clause of a FOR ALL TABLES publication. So fetch + * the publications excluding the topmost ancestor only. + */ + GetRelationPublications(llast_oid(ancestors), NULL, &exceptpuboids); + 1c) + /* Check if the partiton is part of EXCEPT list of any publication */ + GetRelationPublications(RelationGetRelid(attachrel), NULL, &except_pubids= ); + if (except_pubids !=3D NIL) + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("cannot attach relation \"%s\" as partition because it is part of EXCEPT list in publication", + RelationGetRelationName(attachrel)))); + Overall, please take a diff of v35 and v37 to find such parts and please correct these and others (if any). 2) Also I don't think if below is correct statement for Approach 1: + * 2. For a partition, if the topmost ancestor is part of + * the EXCEPT TABLE list, we don't publish it. Even if any ancestor is part of EXECPT list (not only top most) we should not publish that partition, isn't it? 3) I tried a scenario and found that incremental replication is not working correctly. Attached the failing test as Approach1_v37_fail.txt Once these basic things are corrected, I can review further. thanks Shveta --0000000000000e82cb06496bd7e2 Content-Type: text/plain; charset="UTF-8"; name="Approach1_v37_fail.txt" Content-Disposition: attachment; filename="Approach1_v37_fail.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mkxkmlp60 dGFiX3Jvb3QgKFJBTkdFIHJhbmdlX2NvbCkNCuKUnOKUgOKUgCB0YWJfcGFydF8xICgx4oCTMTAw MCkgUEFSVElUSU9OIEJZIFJBTkdFIChpKQ0K4pSCICAg4pSc4pSA4pSAIHRhYl9wYXJ0XzFfcDEg KGkgMOKAkzUwMCkNCuKUgiAgIOKUlOKUgOKUgCB0YWJfcGFydF8xX3AyIChpIDUwMOKAkzEwMDAp DQrilJTilIDilIAgdGFiX3BhcnRfMiAoMTAwMOKAkzIwMDApIFBBUlRJVElPTiBCWSBSQU5HRSAo aSkNCiAgICDilJzilIDilIAgdGFiX3BhcnRfMl9wMSAoaSAw4oCTNTAwKQ0KICAgIOKUlOKUgOKU gCB0YWJfcGFydF8yX3AyIChpIDUwMOKAkzEwMDApDQoJDQpTY2VhbnJpbyAxOgkNCkNSRUFURSBU QUJMRSB0YWJfcm9vdCAocmFuZ2VfY29sIGludCwgaSBpbnQsIGogaW50KSBQQVJUSVRJT04gQlkg UkFOR0UgKHJhbmdlX2NvbCk7DQpDUkVBVEUgVEFCTEUgdGFiX3BhcnRfMSBQQVJUSVRJT04gT0Yg dGFiX3Jvb3QgRk9SIFZBTFVFUyBGUk9NICgxKSBUTyAoMTAwMCkgUEFSVElUSU9OIEJZIFJBTkdF IChpKTsNCkNSRUFURSBUQUJMRSB0YWJfcGFydF8yIFBBUlRJVElPTiBPRiB0YWJfcm9vdCBGT1Ig VkFMVUVTIEZST00gKDEwMDApIFRPICgyMDAwKSBQQVJUSVRJT04gQlkgUkFOR0UgKGkpOw0KDQot LSBMZWFmIHBhcnRpdGlvbnMgdW5kZXIgdGFiX3BhcnRfMQ0KQ1JFQVRFIFRBQkxFIHRhYl9wYXJ0 XzFfcDEgUEFSVElUSU9OIE9GIHRhYl9wYXJ0XzEgRk9SIFZBTFVFUyBGUk9NICgwKSBUTyAoNTAw KTsNCkNSRUFURSBUQUJMRSB0YWJfcGFydF8xX3AyIFBBUlRJVElPTiBPRiB0YWJfcGFydF8xIEZP UiBWQUxVRVMgRlJPTSAoNTAwKSBUTyAoMTAwMCk7DQoNCi0tIExlYWYgcGFydGl0aW9ucyB1bmRl ciB0YWJfcGFydF8yDQpDUkVBVEUgVEFCTEUgdGFiX3BhcnRfMl9wMSBQQVJUSVRJT04gT0YgdGFi X3BhcnRfMiBGT1IgVkFMVUVTIEZST00gKDApIFRPICg1MDApOw0KQ1JFQVRFIFRBQkxFIHRhYl9w YXJ0XzJfcDIgUEFSVElUSU9OIE9GIHRhYl9wYXJ0XzIgRk9SIFZBTFVFUyBGUk9NICg1MDApIFRP ICgxMDAwKTsNCg0KLS0gTGVhZiBwYXJ0aXRpb246IHRhYl9wYXJ0XzFfcDEgKHJhbmdlX2NvbCAx 4oCTMTAwMCwgaSAw4oCTNTAwKSANCklOU0VSVCBJTlRPIHRhYl9yb290IChyYW5nZV9jb2wsIGks IGopIFZBTFVFUyAoMjAwLCAyNTAsIDIpOw0KLS0gTGVhZiBwYXJ0aXRpb246IHRhYl9wYXJ0XzFf cDIgKHJhbmdlX2NvbCAx4oCTMTAwMCwgaSA1MDDigJMxMDAwKSANCklOU0VSVCBJTlRPIHRhYl9y b290IChyYW5nZV9jb2wsIGksIGopIFZBTFVFUyAoMjUwLCA3NTAsIDExKTsNCi0tIExlYWYgcGFy dGl0aW9uOiB0YWJfcGFydF8yX3AxIChyYW5nZV9jb2wgMTAwMOKAkzIwMDAsIGkgMOKAkzUwMCkg DQpJTlNFUlQgSU5UTyB0YWJfcm9vdCAocmFuZ2VfY29sLCBpLCBqKSBWQUxVRVMgKDEzMDAsIDI1 MCwgMjEpOw0KLS0gTGVhZiBwYXJ0aXRpb246IHRhYl9wYXJ0XzJfcDIgKHJhbmdlX2NvbCAxMDAw 4oCTMjAwMCwgaSA1MDDigJMxMDAwKSANCklOU0VSVCBJTlRPIHRhYl9yb290IChyYW5nZV9jb2ws IGksIGopIFZBTFVFUyAoMTcwMCwgNzUwLCAzMSk7DQoNCkNSRUFURSBQVUJMSUNBVElPTiBwdWIx IGZvciBhbGwgdGFibGVzIEVYQ0VQVCh0YWJfcGFydF8xLHRhYl9wYXJ0XzJfcDIpIFdJVEggKFBV QkxJU0hfVklBX1BBUlRJVElPTl9ST09UPXRydWUpOw0KDQpTdWI6DQpDUkVBVEUgVEFCTEUgdGFi X3Jvb3QgKHJhbmdlX2NvbCBpbnQsIGkgaW50LCBqIGludCk7DQpDUkVBVEUgVEFCTEUgdGFiX3Bh cnRfMSAocmFuZ2VfY29sIGludCwgaSBpbnQsIGogaW50KTsNCkNSRUFURSBUQUJMRSB0YWJfcGFy dF8yIChyYW5nZV9jb2wgaW50LCBpIGludCwgaiBpbnQpOw0KQ1JFQVRFIFRBQkxFIHRhYl9wYXJ0 XzFfcDEgKHJhbmdlX2NvbCBpbnQsIGkgaW50LCBqIGludCk7DQpDUkVBVEUgVEFCTEUgdGFiX3Bh cnRfMV9wMiAocmFuZ2VfY29sIGludCwgaSBpbnQsIGogaW50KTsNCkNSRUFURSBUQUJMRSB0YWJf cGFydF8yX3AxIChyYW5nZV9jb2wgaW50LCBpIGludCwgaiBpbnQpOw0KQ1JFQVRFIFRBQkxFIHRh Yl9wYXJ0XzJfcDIgKHJhbmdlX2NvbCBpbnQsIGkgaW50LCBqIGludCk7DQpDUkVBVEUgU1VCU0NS SVBUSU9OIHN1YjEgY29ubmVjdGlvbiAnZGJuYW1lPXBvc3RncmVzIGhvc3Q9bG9jYWxob3N0IHVz ZXI9c2h2ZXRhIHBvcnQ9NTQzMycgcHVibGljYXRpb24gcHViMTsNCg0KLS1Jbml0aWFsIGRhdGEg YmVsb25naW5nIHRvIHRhYl9wYXJ0XzJfcDEgYWxvbmUgc2hvdWxkIHNob3cgdXAgaW4gdGFibGVf cm9vdA0Kc2VsZWN0ICogZnJvbSB0YWJfcm9vdDsNCg0KUHViOg0KLS1Ob3cgdGVzdCBpbmNyZW1l bnRhbCByZXBsaWNhdGlvbjoNCi0tIExlYWYgcGFydGl0aW9uOiB0YWJfcGFydF8xX3AxIChyYW5n ZV9jb2wgMeKAkzEwMDAsIGkgMOKAkzUwMCkgDQpJTlNFUlQgSU5UTyB0YWJfcm9vdCAocmFuZ2Vf Y29sLCBpLCBqKSBWQUxVRVMgKDIwMCwgMjUwLCAyKTsNCi0tIExlYWYgcGFydGl0aW9uOiB0YWJf cGFydF8xX3AyIChyYW5nZV9jb2wgMeKAkzEwMDAsIGkgNTAw4oCTMTAwMCkgDQpJTlNFUlQgSU5U TyB0YWJfcm9vdCAocmFuZ2VfY29sLCBpLCBqKSBWQUxVRVMgKDI1MCwgNzUwLCAxMSk7DQotLSBM ZWFmIHBhcnRpdGlvbjogdGFiX3BhcnRfMl9wMSAocmFuZ2VfY29sIDEwMDDigJMyMDAwLCBpIDDi gJM1MDApIA0KSU5TRVJUIElOVE8gdGFiX3Jvb3QgKHJhbmdlX2NvbCwgaSwgaikgVkFMVUVTICgx MzAwLCAyNTAsIDIxKTsNCi0tIExlYWYgcGFydGl0aW9uOiB0YWJfcGFydF8yX3AyIChyYW5nZV9j b2wgMTAwMOKAkzIwMDAsIGkgNTAw4oCTMTAwMCkgDQpJTlNFUlQgSU5UTyB0YWJfcm9vdCAocmFu Z2VfY29sLCBpLCBqKSBWQUxVRVMgKDE3MDAsIDc1MCwgMzEpOw0KDQpTdWI6DQotLSBFeHBlY3Rh dGlvbjogZGF0YSBiZWxvbmdpbmcgdG8gdGFiX3BhcnRfMl9wMSBhbG9uZSBzaG91bGQgc2hvdyB1 cCBpbiB0YWJfcm9vdC4NCi0tIEFjdHVhbDogdGFiX3BhcnRfMl9wMidzIGRhdGEgYWxzbyBzaG93 IHVwICBpbiB0YWJfcm9vdA0Kc2VsZWN0ICogZnJvbSB0YWJfcm9vdDsNCg0KcG9zdGdyZXM9IyBz ZWxlY3QgKiBmcm9tIHRhYl9yb290Ow0KIHJhbmdlX2NvbCB8ICBpICB8IGogIA0KLS0tLS0tLS0t LS0rLS0tLS0rLS0tLQ0KICAgICAgMTMwMCB8IDI1MCB8IDIxDQogICAgICAxMzAwIHwgMjUwIHwg MjENCiAgICAgIDE3MDAgfCA3NTAgfCAzMSAtLT4gdGFiX3BhcnRfMl9wMiBkYXRhDQooMyByb3dz KQ0KDQoNCn5+DQpTY2VhbnJpbyAyOg0KQ1JFQVRFIFBVQkxJQ0FUSU9OIHB1YjIgZm9yIGFsbCB0 YWJsZXMgRVhDRVBUKHRhYl9yb290KSBXSVRIIChQVUJMSVNIX1ZJQV9QQVJUSVRJT05fUk9PVD10 cnVlKTsNCi0tVGhpcyBnaXZlcyBlcnJvciBvbiBQdWIsIGV4cGVjdGF0aW9uIGlzIG5vIGVycm9y Og0KQ1JFQVRFIFRBQkxFIHRhYl90b3Bfcm9vdCAocmFuZ2VfY29sIGludCwgaSBpbnQsIGogaW50 KSBQQVJUSVRJT04gQlkgUkFOR0UgKHJhbmdlX2NvbCk7IA0KQUxURVIgVEFCTEUgdGFiX3RvcF9y b290IEFUVEFDSCBQQVJUSVRJT04gdGFiX3Jvb3QgRk9SIFZBTFVFUyBGUk9NICgwKSBUTyAoMjAw MCk7DQpFUlJPUjogIGNhbm5vdCBhdHRhY2ggcmVsYXRpb24gInRhYl9yb290IiBhcyBwYXJ0aXRp b24gYmVjYXVzZSBpdCBpcyBwYXJ0IG9mIEVYQ0VQVCBsaXN0IGluIHB1YmxpY2F0aW9uDQoNCg0K --0000000000000e82cb06496bd7e2--