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 1wX2D6-00311h-03 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 19:34:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wX2D4-0087vI-2O for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 19:34:02 +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 1wX2D4-0087v9-0Q for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 19:34:02 +0000 Received: from mail-yw1-x112f.google.com ([2607:f8b0:4864:20::112f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wX2D1-00000001tfj-2QXv for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 19:34:00 +0000 Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-7dd5a8dc8a2so39908247b3.0 for ; Tue, 09 Jun 2026 12:33:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781033639; cv=none; d=google.com; s=arc-20240605; b=fl/XztvGNXZPQk7TGiP61g17ldeJVF1nGzn/rTHWfWJeqOOCPJmJoqS7mJJllGmHxd SgoNgJ3qheZf3o80DyS1T0v9Xgh2pUU74gJWcl+ghpB4Mrurpr409GuwvBx/G5OpFq2/ sI1pVY0Vf/72dS/iUrs2vC6d88ru8140dVrrNBxStBZLC1xdOh7j/m4Lewt8KqRubK0I NJ0QRNxEfnuzDAn3rvLnB4fW7acpvDyV2K9Jkset0sIrodZrQZ7F+DWBqgyb2rdjsxtx mm+6a18zf2ro2nd5+4CoqOgOOmdBCrLPQFFF7JUec4S0HHYCDfeYEylqQHAAobrK3Mdm 15AQ== 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=Ki//c28kXJCFKvZXRL+aNDMagTrgU33KTHeI01kXFg0=; fh=xhPrXOFpZA+sbDgJ5fZ1UF6CdaHLjiNtCoyEiMwI1Do=; b=kghDTpSNLahKhzaN25+oIZ7rrzi2EbKdEItdE2cO0uzDX9zR/ZbFe3ecgJ8IITFTdB yMJ91Jeun2e/ZCi8mL2tOuiGNj/JoYzQvRPa4Arl4GcsXjPTdhCpV2QdD6lkwQ7U+xv/ Q8Mdg40aeFImDQKNIgtHGPQomxPuCvX/Qt9UyxSTySMAeBABAtseFoKjQwDQhe9p0LQe qk99HhLwRy16d6u6LAMDiyoptEQ8xmMwE8mMSYlX3wsyz5xskrCuYmefvvtU1v8QDuxm E6d4pqIiS9wlkJ9qaIHXyyOr6uIL+euDQnRn53WGZO89ZwU4kH+Dgg72HHtXnoKLB4cL 6tLw==; 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=1781033639; x=1781638439; 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=Ki//c28kXJCFKvZXRL+aNDMagTrgU33KTHeI01kXFg0=; b=ss1GfbdkGvtNMuMUM6qF9bogRin8k3+mdtHy+4UnG+O32YcggWMhtenSoFeoX/ql6H E3u+um7JPYDJzRmKPCN64TD5G5euXoPwQwASOSp1mdWzcWTI0r16Xwlqt6RIALGnimRW 1f4wAqxW+Rrc5taaKo7Gitavk5Nuqf73KQXj8rVSnfT8GTWQDkgj+eeIkuWzShhxbDB+ ZxYEJz3vvHfvVdw65hlJWNlr2BueLhGiJw41oHqs7CLKDpEtkDzXNCPox+4pN5/UeTpb tQeiZ/uDg8KoK75j/sBggo5CZzn+/UC576/JmumdGt3oeaRHrec9xiKn1aD/MHOl/WKC GLMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781033639; x=1781638439; 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=Ki//c28kXJCFKvZXRL+aNDMagTrgU33KTHeI01kXFg0=; b=ehDMtgA9aoEwAi2K/9JY6ABxqwYOFAy66vtO3d3oYevsmZZtPxder00pedtJkr9wJj 0ZU9iA1LAA8VeOtUAB+gngXohETOxwRpYdEtWg4vIQ7peduMUXgdwVGtY2pQokZ+xJS1 rr9E8F7eSaiup81ZhNv6GP8jSDXZ2VdcARIhnmUfm5DdtbB86HVPge1dYwFRhF1X1AHX u5YztezlTJeN+oDdYYEUYX+S4kJOJVG7eMYcyny/6deZDPOzA928WJK9Qgcl+RJ+CRfH FzQsKP/cqJLWzkrOcvvL2fEDufCn6JN4zPsiC8bfKVJ76KAw7/tg6liRbyDMcBacv0yD whXQ== X-Forwarded-Encrypted: i=1; AFNElJ/mZcdhDGPXDqLuttKWgu0VLsIeDCHlcjrYFYhedZZVb++lmS7+zqr5zR5quH8TB2M4cDpD1+bCJ/Q0FDRI@lists.postgresql.org X-Gm-Message-State: AOJu0Yy4mR3u/bdO6szy0pQm9pzhDHWWH4+9qW9nupE9oeNJHs/Dmh7Z 90ZvD1B8cepYRuUun3hB0gQ8gJmN83wFHNJmjG7JMLQxjBwgxH6DXtserB/qZRPQcss3FU5ErUl dRlr3LVdsmpZZvrQ7sopexPB/MUkq3ks= X-Gm-Gg: Acq92OG9PapMFzOdujL5csRNgxdjq2JncGXZZZbjwOSsvDnVji8AYkEasSamj4ac9kC RV4WAasMwCKFjJax40JOeIc9o8Sx3g7D0E2yZxq8TFJYRuJVgQDxtFKij5ZhbTW3M37nCdnTXYa Ou2CJCgQqvOqaTS0qkxy7WyzrEl6lLjBNmsWuYrBYEpbgw0TrCWr11rwMEGP7kwlpynQD0pLsuF +aLWSMp/j+SkCeHoIpC/eLaqrVBB52LF218TgFsz8kI8T4jDztp++tNKI9ps7dG9/Tr+z+IzFBW /zp/X1YQy3Ea4ynYcfWTefkcYN8JY95YEcNwLUZh5JT/zRpkaA== X-Received: by 2002:a05:690c:e3d1:b0:79a:60f6:c5ed with SMTP id 00721157ae682-7ed0d3cbcc4mr211903197b3.6.1781033638519; Tue, 09 Jun 2026 12:33:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ayush Tiwari Date: Wed, 10 Jun 2026 01:03:45 +0530 X-Gm-Features: AVVi8Cc7lk0Cy8yN3kXGPwUkZEVv_GX2upLThBINDoF0PBFF7wm6nPbqFiedxm4 Message-ID: Subject: Re: [Bug] Add the missing RTE_GRAPH_TABLE case to transformLockingClause() To: Ashutosh Bapat , Peter Eisentraut Cc: SATYANARAYANA NARLAPURAM , PostgreSQL Hackers Content-Type: multipart/mixed; boundary="0000000000005b93170653d73529" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005b93170653d73529 Content-Type: multipart/alternative; boundary="0000000000005b93160653d73527" --0000000000005b93160653d73527 Content-Type: text/plain; charset="UTF-8" Hi, On Wed, 13 May 2026 at 10:57, Ashutosh Bapat wrote: > > Repro: > > > > CREATE TABLE v(id int PRIMARY KEY, vname text); > > CREATE PROPERTY GRAPH g VERTEX TABLES (v); > > SELECT * FROM GRAPH_TABLE(g MATCH (a) COLUMNS (a.vname)) gt > > FOR UPDATE OF gt; > > -- ERROR: unrecognized RTE type: 8 > > > > Attached a patch that returns ERRCODE_FEATURE_NOT_SUPPORTED "FOR ... > cannot be > > applied to a GRAPH_TABLE" with a position pointer, matching the > convention used by > > the function/tablefunc etc. > > In a fully matured SQL/PGQ support, a row mark on GRAPH_TABLE should > be pushed down to the resulting subqueries in rewriteGraphTable(). I > see this similar to how the row mark is pushed down into views during > the rewrite phase. I don't think the code changes will be massive, it > will be a matter of invoking markQueryForLocking() on the query that > replaces the graph pattern in rewriteGraphTable(). I am not sure > whether we want to do that now when stabilizing the feature. Peter, > what do you think? > I wanted to implement this by trying to push FOR UPDATE/SHARE down into the relational tables underlying the GRAPH_TABLE (the "fully matured SQL/PGQ" direction mentioned). But had some doubts around the implementation. I'd like input on a few design questions from you/Peter/hackers: Q1. Is the right place to do the pushdown rewriteGraphTable(), mirroring what ApplyRetrieveRule() does for views (i.e. call markQueryForLocking() on the freshly built subquery)? That would require exposing markQueryForLocking() outside rewriteHandler.c. Q2. How should FOR UPDATE behave when the MATCH expands to more than one path and rewriteGraphTable() produces a UNION? markQueryForLocking() refuses to descend into set-operations, same as it does for views. Options: (a) reject FOR UPDATE on multi-path MATCH with a clear "cannot lock rows from a set-operation result" error, matching the view behaviour; (b) silently fall back to the current "raise relation lock only" behaviour and document it. I think it should be (a). Q3. SQL/PGQ does not really define UPDATE/DELETE semantics for graph paths. Is the intent here that FOR UPDATE/SHARE on GRAPH_TABLE is purely a concurrency hint rather than a precursor to UPDATE WHERE CURRENT OF? If so, that should probably be documented next to the GRAPH_TABLE syntax in the SQL reference. > If we decide to not to support it, the code changes look on the right > path. We need to update the following comment which appears earlier in > the function to mention GRAPH_TABLE, /* ignore JOIN, SPECIAL, > FUNCTION, VALUES, CTE RTEs */. I think it will be better to specify > that this restriction is temporary in the comments at both the places; > but that's arguable. > > > Patch includes tests for all four locking strengths. > > Since the code path looks simple we can just keep one of them as well > and trim other > > tests. Thoughts? > > I don't think we need all the four tests, but we need a test for > locking clause without relation since that takes a different code > path. > Attached is v2-0001, rebased on master and addressing the comments you added in case we plan on parking the feature work for once v20 opens. Regards, Ayush --0000000000005b93160653d73527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On We= d, 13 May 2026 at 10:57, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
> Repro:
>
>=C2=A0 =C2=A0CREATE TABLE v(id int PRIMARY KEY, vname text);
>=C2=A0 =C2=A0CREATE PROPERTY GRAPH g VERTEX TABLES (v);
>=C2=A0 =C2=A0SELECT * FROM GRAPH_TABLE(g MATCH (a) COLUMNS (a.vname)) g= t
>=C2=A0 =C2=A0 =C2=A0FOR UPDATE OF gt;
>=C2=A0 =C2=A0-- ERROR:=C2=A0 unrecognized RTE type: 8
>
> Attached a patch that returns ERRCODE_FEATURE_NOT_SUPPORTED "FOR = ... cannot be
> applied to a GRAPH_TABLE" with a position pointer, matching the c= onvention used by
> the function/tablefunc etc.

In a fully matured SQL/PGQ support, a row mark on GRAPH_TABLE should
be pushed down to the resulting subqueries in rewriteGraphTable(). I
see this similar to how the row mark is pushed down into views during
the rewrite phase. I don't think the code changes will be massive, it will be a matter of invoking markQueryForLocking() on the query that
replaces the graph pattern in rewriteGraphTable(). I am not sure
whether we want to do that now when stabilizing the feature. Peter,
what do you think?

I wanted to implemen= t this by trying to push=C2=A0 FOR UPDATE/SHARE
down into the relational= tables underlying the GRAPH_TABLE (the
"fully matured SQL/PGQ"= ; direction mentioned). But had
some doubts around the implementation.
I'd like input on a few design questions from you/Peter/hackers:<= br>
=C2=A0 Q1. Is the right place to do the pushdown rewriteGraphTable()= ,
=C2=A0 =C2=A0 =C2=A0 mirroring what ApplyRetrieveRule() does for views= (i.e. call
=C2=A0 =C2=A0 =C2=A0 markQueryForLocking() on the freshly bu= ilt subquery)?=C2=A0 That
=C2=A0 =C2=A0 =C2=A0 would require exposing ma= rkQueryForLocking() outside
=C2=A0 =C2=A0 =C2=A0 rewriteHandler.c.
=C2=A0 Q2. How should FOR UPDATE behave when the MATCH expands to more=C2=A0 =C2=A0 =C2=A0 than one path and rewriteGraphTable() produces a UNIO= N?
=C2=A0 =C2=A0 =C2=A0 markQueryForLocking() refuses to descend into se= t-operations,
=C2=A0 =C2=A0 =C2=A0 same as it does for views.=C2=A0 Opti= ons:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) reject FOR UPDATE on multi-path MAT= CH with a clear
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "cannot l= ock rows from a set-operation result" error,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 matching the view behaviour;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 (b) silently fall back to the current
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 "raise relation lock only" behaviour and document = it.
=C2=A0 =C2=A0 =C2=A0 I think it should be (a).

=C2=A0 Q3. SQL= /PGQ does not really define UPDATE/DELETE semantics for
=C2=A0 =C2=A0 = =C2=A0 graph paths.=C2=A0 Is the intent here that FOR UPDATE/SHARE on
= =C2=A0 =C2=A0 =C2=A0 GRAPH_TABLE is purely a concurrency hint rather than a=
=C2=A0 =C2=A0 =C2=A0 precursor to UPDATE WHERE CURRENT OF?=C2=A0 If so= , that should
=C2=A0 =C2=A0 =C2=A0 probably be documented next to the G= RAPH_TABLE syntax in
=C2=A0 =C2=A0 =C2=A0 the SQL reference.
=C2=A0<= /div>
If we decide to not to support it, the code changes look on the right
path. We need to update the following comment which appears earlier in
the function to mention GRAPH_TABLE, /* ignore JOIN, SPECIAL,
FUNCTION, VALUES, CTE RTEs */. I think it will be better to specify
that this restriction is temporary in the comments at both the places;
but that's arguable.

> Patch includes tests for all four locking strengths.
> Since the code path looks simple we can just keep one of them as well = and trim other
> tests. Thoughts?

I don't think we need all the four tests, but we need a test for
locking clause without relation since that takes a different code
path.

Attached is v2-0001, rebased on m= aster and addressing
the comments you added in case we plan on pa= rking the feature
work for once v20 opens.=C2=A0

Regards,<= br>Ayush
--0000000000005b93160653d73527-- --0000000000005b93170653d73529 Content-Type: application/octet-stream; name="v2-0001-Add-the-missing-RTE_GRAPH_TABLE-case-to-transform.patch" Content-Disposition: attachment; filename="v2-0001-Add-the-missing-RTE_GRAPH_TABLE-case-to-transform.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mq71dqta0 RnJvbSA4Yzc1YjBkOTRlNTA3YTYwNjE2ZDMwNGU4NTE1MzQ2MWNmOTZjMmM1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBeXVzaCBUaXdhcmkgPGF5dXNodGl3YXJpLnNsZzAxQGdtYWls LmNvbT4KRGF0ZTogVHVlLCA5IEp1biAyMDI2IDIwOjE0OjEzICswNTMwClN1YmplY3Q6IFtQQVRD SCB2Ml0gQWRkIHRoZSBtaXNzaW5nIFJURV9HUkFQSF9UQUJMRSBjYXNlIHRvCiB0cmFuc2Zvcm1M b2NraW5nQ2xhdXNlKCkKCkEgRk9SIFVQREFURS9TSEFSRSBjbGF1c2UgdGhhdCBuYW1lcyBhIEdS QVBIX1RBQkxFIGFsaWFzIGhpdCB0aGUKaW50ZXJuYWwgInVucmVjb2duaXplZCBSVEUgdHlwZSIg ZXJyb3IgcmF0aGVyIHRoYW4gYSB1c2VyLWZyaWVuZGx5CiJGT1IgLi4uIGNhbm5vdCBiZSBhcHBs aWVkIHRvIGEgR1JBUEhfVEFCTEUiIG1lc3NhZ2U6CgogICAgQ1JFQVRFIFRBQkxFIHYoaWQgaW50 IFBSSU1BUlkgS0VZLCB2bmFtZSB0ZXh0KTsKICAgIENSRUFURSBQUk9QRVJUWSBHUkFQSCBnIFZF UlRFWCBUQUJMRVMgKHYpOwogICAgU0VMRUNUICogRlJPTSBHUkFQSF9UQUJMRShnIE1BVENIIChh KSBDT0xVTU5TIChhLnZuYW1lKSkgZ3QKICAgICAgRk9SIFVQREFURSBPRiBndDsKICAgIC0tIEVS Uk9SOiB1bnJlY29nbml6ZWQgUlRFIHR5cGU6IDgKCkFkZCBhbiBleHBsaWNpdCBjYXNlIGZvciBS VEVfR1JBUEhfVEFCTEUgdGhhdCByYWlzZXMKRVJSQ09ERV9GRUFUVVJFX05PVF9TVVBQT1JURUQs IG1hdGNoaW5nIHRoZSBjb252ZW50aW9uIGFscmVhZHkgdXNlZApmb3IgUlRFX0ZVTkNUSU9OLCBS VEVfVEFCTEVGVU5DLCBSVEVfVkFMVUVTLCBSVEVfQ1RFIGFuZApSVEVfTkFNRURUVVBMRVNUT1JF LiAgVGVzdHMgY292ZXIgYm90aCB0aGUgbmFtZWQtcmVsIGFuZCB0aGUKYWxsLXJlbHMgY29kZSBw YXRocy4KCkF1dGhvcjogU0FUWUFOQVJBWUFOQSBOQVJMQVBVUkFNIDxzYXR5YW5hcmxhcHVyYW1A Z21haWwuY29tPgpSZXBvcnRlZC1ieTogU0FUWUFOQVJBWUFOQSBOQVJMQVBVUkFNIDxzYXR5YW5h cmxhcHVyYW1AZ21haWwuY29tPgpSZXZpZXdlZC1ieTogWmhlbndlaSBTaGFuZyA8YTkzNDE3MjQ0 MkBnbWFpbC5jb20+ClJldmlld2VkLWJ5OiBBc2h1dG9zaCBCYXBhdCA8YXNodXRvc2guYmFwYXQu b3NzQGdtYWlsLmNvbT4KRGlzY3Vzc2lvbjogaHR0cHM6Ly9wb3N0Z3IuZXMvbS9DQUhnJTJCUURj RTl3cDZuT0VDM1NDUlE5MG5yQ08lM0RRRiUyQk9acTFNRzhRYzZobnVzbW9ncXclNDBtYWlsLmdt YWlsLmNvbQotLS0KIHNyYy9iYWNrZW5kL3BhcnNlci9hbmFseXplLmMgICAgICAgICAgICAgIHwg MTYgKysrKysrKysrKysrKysrLQogc3JjL3Rlc3QvcmVncmVzcy9leHBlY3RlZC9ncmFwaF90YWJs ZS5vdXQgfCAxNiArKysrKysrKysrKysrKysrCiBzcmMvdGVzdC9yZWdyZXNzL3NxbC9ncmFwaF90 YWJsZS5zcWwgICAgICB8ICA3ICsrKysrKysKIDMgZmlsZXMgY2hhbmdlZCwgMzggaW5zZXJ0aW9u cygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3BhcnNlci9hbmFs eXplLmMgYi9zcmMvYmFja2VuZC9wYXJzZXIvYW5hbHl6ZS5jCmluZGV4IDkzZmE2NmFlNTdjLi43 NDI5NDU4MWVmOSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcGFyc2VyL2FuYWx5emUuYworKysg Yi9zcmMvYmFja2VuZC9wYXJzZXIvYW5hbHl6ZS5jCkBAIC0zODY2LDcgKzM4NjYsNyBAQCB0cmFu c2Zvcm1Mb2NraW5nQ2xhdXNlKFBhcnNlU3RhdGUgKnBzdGF0ZSwgUXVlcnkgKnFyeSwgTG9ja2lu Z0NsYXVzZSAqbGMsCiAJCQkJCQkJCQkJICAgYWxscmVscywgdHJ1ZSk7CiAJCQkJCWJyZWFrOwog CQkJCWRlZmF1bHQ6Ci0JCQkJCS8qIGlnbm9yZSBKT0lOLCBTUEVDSUFMLCBGVU5DVElPTiwgVkFM VUVTLCBDVEUgUlRFcyAqLworCQkJCQkvKiBpZ25vcmUgSk9JTiwgU1BFQ0lBTCwgRlVOQ1RJT04s IFZBTFVFUywgQ1RFLCBHUkFQSF9UQUJMRSAqLwogCQkJCQlicmVhazsKIAkJCX0KIAkJfQpAQCAt NDAwMSw2ICs0MDAxLDIwIEBAIHRyYW5zZm9ybUxvY2tpbmdDbGF1c2UoUGFyc2VTdGF0ZSAqcHN0 YXRlLCBRdWVyeSAqcXJ5LCBMb2NraW5nQ2xhdXNlICpsYywKIAkJCQkJCQkJCQkJTENTX2FzU3Ry aW5nKGxjLT5zdHJlbmd0aCkpLAogCQkJCQkJCQkJIHBhcnNlcl9lcnJwb3NpdGlvbihwc3RhdGUs IHRoaXNyZWwtPmxvY2F0aW9uKSkpOwogCQkJCQkJCWJyZWFrOworCQkJCQkJY2FzZSBSVEVfR1JB UEhfVEFCTEU6CisJCQkJCQkJLyoKKwkJCQkJCQkgKiBYWFg6IHB1c2ggdGhlIHJvdyBtYXJrIGRv d24gdG8gdGhlCisJCQkJCQkJICogcmVsYXRpb25zIHRoZSBHUkFQSF9UQUJMRSBleHBhbmRzIHRv CisJCQkJCQkJICogZHVyaW5nIHJld3JpdGluZy4KKwkJCQkJCQkgKi8KKwkJCQkJCQllcmVwb3J0 KEVSUk9SLAorCQkJCQkJCQkJKGVycmNvZGUoRVJSQ09ERV9GRUFUVVJFX05PVF9TVVBQT1JURUQp LAorCQkJCQkJCS8qLS0tLS0tCisJCQkJCQkJICB0cmFuc2xhdG9yOiAlcyBpcyBhIFNRTCByb3cg bG9ja2luZyBjbGF1c2Ugc3VjaCBhcyBGT1IgVVBEQVRFICovCisJCQkJCQkJCQkgZXJybXNnKCIl cyBjYW5ub3QgYmUgYXBwbGllZCB0byBhIEdSQVBIX1RBQkxFIiwKKwkJCQkJCQkJCQkJTENTX2Fz U3RyaW5nKGxjLT5zdHJlbmd0aCkpLAorCQkJCQkJCQkJIHBhcnNlcl9lcnJwb3NpdGlvbihwc3Rh dGUsIHRoaXNyZWwtPmxvY2F0aW9uKSkpOworCQkJCQkJCWJyZWFrOwogCiAJCQkJCQkJLyogU2hv dWxkbid0IGJlIHBvc3NpYmxlIHRvIHNlZSBSVEVfUkVTVUxUIGhlcmUgKi8KIApkaWZmIC0tZ2l0 IGEvc3JjL3Rlc3QvcmVncmVzcy9leHBlY3RlZC9ncmFwaF90YWJsZS5vdXQgYi9zcmMvdGVzdC9y ZWdyZXNzL2V4cGVjdGVkL2dyYXBoX3RhYmxlLm91dAppbmRleCA3MGQ5ODZlOGFiMC4uZDk1NzUy Y2Y5MmMgMTAwNjQ0Ci0tLSBhL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvZ3JhcGhfdGFibGUu b3V0CisrKyBiL3NyYy90ZXN0L3JlZ3Jlc3MvZXhwZWN0ZWQvZ3JhcGhfdGFibGUub3V0CkBAIC0x MDc3LDQgKzEwNzcsMjAgQEAgU0VMRUNUIHNyYy52bmFtZSwgY291bnQoKikgRlJPTSB2MSBBUyBz cmMKICB2MTMgICB8ICAgICAxCiAoMyByb3dzKQogCistLSBGT1IgVVBEQVRFL1NIQVJFIG9uIEdS QVBIX1RBQkxFOiBub3Qgc3VwcG9ydGVkIHdoZW4gdGhlIGFsaWFzIGlzIG5hbWVkCistLSBpbiB0 aGUgbG9ja2luZyBjbGF1c2U7IHNpbGVudGx5IGlnbm9yZWQgd2hlbiBubyByZWxhdGlvbnMgYXJl IG5hbWVkLgorU0VMRUNUICogRlJPTSBHUkFQSF9UQUJMRSAoZzEgTUFUQ0ggKHNyYyBJUyB2bDEp IENPTFVNTlMgKHNyYy52bmFtZSkpIGd0CisgIEZPUiBVUERBVEUgT0YgZ3Q7ICAtLSBlcnJvcgor RVJST1I6ICBGT1IgVVBEQVRFIGNhbm5vdCBiZSBhcHBsaWVkIHRvIGEgR1JBUEhfVEFCTEUKK0xJ TkUgMjogICBGT1IgVVBEQVRFIE9GIGd0OworICAgICAgICAgICAgICAgICAgICAgICAgXgorU0VM RUNUICogRlJPTSBHUkFQSF9UQUJMRSAoZzEgTUFUQ0ggKHNyYyBJUyB2bDEpIENPTFVNTlMgKHNy Yy52bmFtZSkpIGd0CisgIEZPUiBVUERBVEU7ICAtLSBvaywgbG9jayBzaWxlbnRseSBza2lwcGVk IGZvciBHUkFQSF9UQUJMRQorIHZuYW1lIAorLS0tLS0tLQorIHYxMQorIHYxMgorIHYxMworKDMg cm93cykKKwogLS0gbGVhdmUgdGhlIG9iamVjdHMgYmVoaW5kIGZvciBwZ191cGdyYWRlL3BnX2R1 bXAgdGVzdHMKZGlmZiAtLWdpdCBhL3NyYy90ZXN0L3JlZ3Jlc3Mvc3FsL2dyYXBoX3RhYmxlLnNx bCBiL3NyYy90ZXN0L3JlZ3Jlc3Mvc3FsL2dyYXBoX3RhYmxlLnNxbAppbmRleCAwYjQ0ZjcwZDdl Ny4uMzk3NmRiNGUyMzEgMTAwNjQ0Ci0tLSBhL3NyYy90ZXN0L3JlZ3Jlc3Mvc3FsL2dyYXBoX3Rh YmxlLnNxbAorKysgYi9zcmMvdGVzdC9yZWdyZXNzL3NxbC9ncmFwaF90YWJsZS5zcWwKQEAgLTYx Miw0ICs2MTIsMTEgQEAgU0VMRUNUIHNyYy52bmFtZSwgY291bnQoKikgRlJPTSB2MSBBUyBzcmMK ICAgSEFWSU5HIGNvdW50KCopID49IChTRUxFQ1QgY291bnQoKikgRlJPTSBHUkFQSF9UQUJMRSAo ZzEgTUFUQ0ggKGEgSVMgdmwxIHwgdmwyKSBDT0xVTU5TIChhLnZuYW1lIEFTIG4pKSBXSEVSRSBu ID0gc3JjLnZuYW1lKQogICBPUkRFUiBCWSB2bmFtZTsKIAorLS0gRk9SIFVQREFURS9TSEFSRSBv biBHUkFQSF9UQUJMRTogbm90IHN1cHBvcnRlZCB3aGVuIHRoZSBhbGlhcyBpcyBuYW1lZAorLS0g aW4gdGhlIGxvY2tpbmcgY2xhdXNlOyBzaWxlbnRseSBpZ25vcmVkIHdoZW4gbm8gcmVsYXRpb25z IGFyZSBuYW1lZC4KK1NFTEVDVCAqIEZST00gR1JBUEhfVEFCTEUgKGcxIE1BVENIIChzcmMgSVMg dmwxKSBDT0xVTU5TIChzcmMudm5hbWUpKSBndAorICBGT1IgVVBEQVRFIE9GIGd0OyAgLS0gZXJy b3IKK1NFTEVDVCAqIEZST00gR1JBUEhfVEFCTEUgKGcxIE1BVENIIChzcmMgSVMgdmwxKSBDT0xV TU5TIChzcmMudm5hbWUpKSBndAorICBGT1IgVVBEQVRFOyAgLS0gb2ssIGxvY2sgc2lsZW50bHkg c2tpcHBlZCBmb3IgR1JBUEhfVEFCTEUKKwogLS0gbGVhdmUgdGhlIG9iamVjdHMgYmVoaW5kIGZv ciBwZ191cGdyYWRlL3BnX2R1bXAgdGVzdHMKLS0gCjIuMzQuMQoK --0000000000005b93170653d73529--