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 1wFyJ4-005kzr-29 for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 17:57:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFyJ3-002fu5-2d for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 17:57:41 +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 1wFyJ3-002ftq-0s for pgsql-hackers@lists.postgresql.org; Thu, 23 Apr 2026 17:57:41 +0000 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wFyIz-00000002S8t-46Wj for pgsql-hackers@postgresql.org; Thu, 23 Apr 2026 17:57:39 +0000 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-404254ffe8aso4885413fac.0 for ; Thu, 23 Apr 2026 10:57:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776967057; cv=none; d=google.com; s=arc-20240605; b=PP/8MvcImebDZc5W5GrTTmwEdyT1YoF3vJpfsI8d4MK4Y1EAnhioRFH8citdGZAEpH lQfOF9bx6aLqkKWTxzKgVSZFSDDNQPDm2PkQdm8WuCL6Ql5kfziRY7gMofitLuJX2oop 5/f72nGjzpSKSuEWMu+c4K82ln42n74Ised7OQ3Hp8fXsW5Bu3foA5ykn4s3+OrQXnaW Dz/4jizzm3i7ZAXhkVlU+7yNgy8yyxu24JopO55Zu6lSFE7YTSHdE+2lE1Gp2/BNpkyp TnrwUtcchqybeidV1Q7mu7lL8pZgjENXnHk5ScznT9hhJ2qAYaJsraaf17Dodpzg0cHF wZpQ== 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=6p5H/Yh70s4nOsZ5lADQNz6F0VFAnunaCBk97mNJwdk=; fh=yJtAqcf+LfhPFXexoNcHEH0KZlnHgCeK4GHd+C/oiUA=; b=bJniPxCASt8yhsvALaT08vlY6rnkkzi73SjmVGJ1kVr8ijX8wzG3vlYtm7BV++57vC ET5xBXLszMubo3MEfV92uYRULe6sBWqx2bKwPWUSdLx9ue68yytlLmn1lWWUdjnYYWiv NVbpw6HRrEArqGNmbiDjgGKeC3Ss23R7uhrwDEZg+sp0SJjpXC+xhcqDqWa636PnZaYr YG4WBSHGp35eUl3BY3Q5dSpyeeALb0DVbztwPTzK/ZfY3ErkPae77hG94zvN5N7S60F6 L2X3BOKBAlZTRRHw6pWCPd3O8Hqd/1QM0SJzUiFnchYpDz+mYLMsSDNxErtAtyLg9xm1 5qpQ==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1776967057; x=1777571857; darn=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=6p5H/Yh70s4nOsZ5lADQNz6F0VFAnunaCBk97mNJwdk=; b=WE6iqMDHV92tpdtAZzFNcw15BqW0zSC5zO/t15+7Xa7WM50nRHMTk2kpM2JLSMOPPv IapykOXuw4ExHt9kSv9cOtCJG5pzYtcPx1r4g+7+0wgxI4C40+B1IlMaDA+u2bWON9zs ZCFISrAcErFvXfz168WcCavOv9C9WUxkh32nVK1OlTr52mCa0L8rWXj33l8hmXZgz7UG RdmAyg6trsLVhUiZgdMGG4+t2dSiP55pnxG8C+vQGs+cK9KVI0Il65GcP0Mo97QlQXBq Lik3br9w3VZ3ih+DPenCeU3n8R1aTvb5HiC/X+LxMUMVPZvUIv6IhIUm3ntCz14SlPg8 Tv3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776967057; x=1777571857; 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=6p5H/Yh70s4nOsZ5lADQNz6F0VFAnunaCBk97mNJwdk=; b=NJMjc+mMrWYnLioOdTWhjt/ClDspJ0ueL/i0kyGTIfYTyDlx+ukArXfQ94h3lUuht4 bsm/w/fi02MzR3juuBf8PWb/cUlJniJYehJDxz4+g5hwcznT/1ESWW4mh6SvbP/9G1F4 kjG95DTuTXEgWt3/i7jjYKYV/vmTfCbnxAayp+pIxH28lZmiKqmx1yt/2rsAJ0Y5DLsP cm2X8w26j9aZ2MLqfWB1r8hoN1+GZuRpp4kUg+EE5VDfX5FyFdrFcwjvnK10t74KhEy3 YTpbxkxycajhi0xlY5eIMl5Q60zx8Muqn9TPpvEYrAYuW/aW462cQbrg9ZGtLtEPH9rX tRTw== X-Forwarded-Encrypted: i=1; AFNElJ8IxULxafYgVbIxNyUITk2fG/PIHPKGnH7PgUJZ/G6zNSfYugd/QNx1cUbnmZ3a7R0BzsT3I9WQWg47r+jz@postgresql.org X-Gm-Message-State: AOJu0YwzAOFUvkaOc5cx3+pC2ZAOKqSaE4zKHhJSlLZxrICTNmk/SIVx eJcxr8Ys6RXHI/rP3mOeYAA2wkCREAyAmB/miXq4MFy4JvFhkYU6s9LQt+icciPAJE2ElKf2DAi I3DXD94I+TFtfOvMYOKlzJ1DWhUkziyo4jgPonekP X-Gm-Gg: AeBDiet3BcWh430s5a7a4BFzUg1XbPXzJFSdDzJPS/p6p/Y1GL8NPf3iaHVfntqRmmP vZdOcF9RLYYBAej0NVGYXghUp9eyjCzNgh4WWGYr69YMiPZiLOrwGnCahWGR7OYStnj5+tNrczl AXXMT+4Wc+Kja7BEj7P8kA8tmTnJdInN+aKcfyCZmXU5bCC8m6G1dOGh3O6yfEfuHdcbmcSO29Y CtNXFDqsi2/Y/Zyz5yj483cG+5QHGaxWJwyFVcoqdgBHLl/gsLUUQDesclStAu5gFBcuhVTdIeG kTjRC5MJ55LV1n1pyfA2 X-Received: by 2002:a05:6871:3a0c:b0:3f9:d552:f34 with SMTP id 586e51a60fabf-42a99a1f849mr14274194fac.14.1776967056975; Thu, 23 Apr 2026 10:57:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Dilger Date: Thu, 23 Apr 2026 10:57:28 -0700 X-Gm-Features: AQROBzC6nDi5FUCpTwciVh96TbU36ch8UpIisRrX4eD1pFptqsnfrTWAA6qdSfM Message-ID: Subject: Re: GUC parameter ACLs and physical walsender To: John Naylor Cc: Jeff Davis , pgsql-hackers@postgresql.org, Andrey Borodin Content-Type: multipart/alternative; boundary="00000000000035822d06502462b6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000035822d06502462b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 22, 2026 at 8:27=E2=80=AFPM John Naylor wrote: > On Thu, Apr 23, 2026 at 2:19=E2=80=AFAM Jeff Davis wr= ote: > > It seems to be because pg_parameter_acl is not nailed in cache. I > > attached a quick patch to do so (which turns it into the "expected > > permission denied" error). But I'm not sure if that's the right fix, or > > if it would be a complete fix. I also don't think that would be > > backportable, but perhaps? > > I think in existing installations AddNewRelationType() would have > picked some oid already, so fixing rowtype_oid at initdb time would > only work in the master branch. > John is right that the hardcoded BKI_ROWTYPE_OID(2173) makes this non-backportable as-is. On existing installations (PG 15-18), AddNewRelationType() assigned rowtype OID 10097 to pg_parameter_acl during initdb. Jeff's patch has formrdesc set rd_att->tdtypeid =3D 2173, but that field is never corrected =E2=80=94 Phas= e3 overwrites rd_rel (including reltype) via memcpy, but rd_att->tdtypeid stays at the formrdesc value. The comment in formrdesc says as much: "this data had better be right because it will never be replaced." On assert-enabled builds, every backend crashes on the first connection: TRAP: failed Assert("relation->rd_att->tdtypeid =3D=3D relp->reltype"), File: "relcache.c", Line: 4294 On non-assert builds, the mismatch has no observable effect. The wrong typeId gets stamped into pg_parameter_acl tuple headers by heap_form_tuple, but nothing reads it back -- all consumers of HeapTupleHeaderGetTypeId are in the executor, PL/pgSQL, and record-type processing, not catalog operations. For backports, formrdesc would need to use something other than the hardcoded OID -- either look up the real rowtype OID, or pass InvalidOid and teach th= e Assert to tolerate it for late-nailed relations. To demonstrate, using an existing cluster whose initdb was done without the nailing patch (rowtype 10097), then started with patched binaries: after applying Jeff's v1-0001-Nail-pg_parameter_acl-in-relcache.patch to master, which has dbf217c1c7 already applied: --- a/src/backend/utils/cache/relcache.c +++ b/src/backend/utils/cache/relcache.c @@ -1965,6 +1965,12 @@ formrdesc(const char *relationName, Oid relationReltype, relation->rd_att->tdtypeid =3D relationReltype; relation->rd_att->tdtypmod =3D -1; /* just to be sure */ + elog(LOG, "formrdesc \"%s\": relid=3D%u reltype=3D%u tdtypeid=3D%u", + relationName, + TupleDescAttr(relation->rd_att, 0)->attrelid, + relationReltype, + relation->rd_att->tdtypeid); + /* * initialize tuple desc info */ @@ -4283,6 +4289,14 @@ RelationCacheInitializePhase3(void) * data correctly to start with, because it may already have been * copied into one or more catcache entries.) */ + elog(LOG, "RelationCacheInitializePhase3 \"%s\": relid=3D%u " + "formrdesc tdtypeid=3D%u, pg_class reltype=3D%u%s", + RelationGetRelationName(relation), + RelationGetRelid(relation), + relation->rd_att->tdtypeid, + relp->reltype, + (relation->rd_att->tdtypeid !=3D relp->reltype) + ? " MISMATCH" : ""); Assert(relation->rd_att->tdtypeid =3D=3D relp->reltype); Assert(relation->rd_att->tdtypmod =3D=3D -1); On an existing cluster with patched binaries it shows: formrdesc "pg_parameter_acl": relid=3D0 reltype=3D2173 tdtypeid=3D2173 RelationCacheInitializePhase3 "pg_parameter_acl": relid=3D6243 formrdesc tdtypeid=3D2173, pg_class reltype=3D10097 MISMATCH --=20 *Mark Dilger* --00000000000035822d06502462b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 22,= 2026 at 8:27=E2=80=AFPM John Naylor <johncnaylorls@gmail.com> wrote:
On Thu, Apr 23, 2026 at 2:19=E2=80=AFAM Je= ff Davis <pgsql@j= -davis.com> wrote:
> It seems to be because pg_parameter_acl is not nailed in cache. I
> attached a quick patch to do so (which turns it into the "expecte= d
> permission denied" error). But I'm not sure if that's the= right fix, or
> if it would be a complete fix. I also don't think that would be > backportable, but perhaps?

I think in existing installations AddNewRelationType() would have
picked some oid already, so fixing rowtype_oid at initdb time would
only work in the master branch.

John is= right that the hardcoded BKI_ROWTYPE_OID(2173) makes this
non-backporta= ble as-is.
=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=A0 =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=A0 =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=A0 =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=A0 =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=A0 =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=A0
On existing installations= (PG 15-18), AddNewRelationType() assigned rowtype OID
10097 to pg_param= eter_acl during initdb. Jeff's patch has formrdesc set
rd_att->td= typeid =3D 2173, but that field is never corrected =E2=80=94 Phase3 overwri= tes
rd_rel (including reltype) via memcpy, but rd_att->tdtypeid stays= at the
formrdesc value. The comment in formrdesc says as much: "th= is data had better
be right because it will never be replaced."
= =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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
On assert-enabled = builds, every backend crashes on the first connection: =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=A0 =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=A0 =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=A0 =C2=A0 =C2=A0
=C2=A0
TRAP: failed Ass= ert("relation->rd_att->tdtypeid =3D=3D relp->reltype"), = =C2=A0
=C2=A0 File: "relcache.c", Line: 4294 =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=A0 = =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=A0 =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=A0 =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=A0 =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=A0 = =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=A0 =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=A0 =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=A0
On non-assert buil= ds, the mismatch has no observable effect. The wrong typeId
gets stamped= into pg_parameter_acl tuple headers by heap_form_tuple, but
nothing rea= ds it back -- all consumers of HeapTupleHeaderGetTypeId are in the
execu= tor, PL/pgSQL, and record-type processing, not catalog operations.
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
Fo= r backports, formrdesc would need to use something other than the hardcoded=
OID -- either look up the real rowtype OID, or pass InvalidOid and teac= h the
Assert to tolerate it for late-nailed relations.
=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= =A0 =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=A0 =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=A0 =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=A0 =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=A0 = =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=A0
To demonstrate, using an existing cluster whose initd= b was done without the
nailing patch (rowtype 10097), then starte= d with patched binaries: =C2=A0after applying
Jeff's v1-0001-= Nail-pg_parameter_acl-in-relcache.patch to master, which has
dbf2= 17c1c7 already applied:

--- a/src/backend/utils/ca= che/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -1965,6 +1= 965,12 @@ formrdesc(const char *relationName, Oid relationReltype,
=C2= =A0 =C2=A0 relation->rd_att->tdtypeid =3D relationReltype;
=C2=A0 = =C2=A0 relation->rd_att->tdtypmod =3D -1; =C2=A0 =C2=A0/* just to be = sure */

+ =C2=A0 elog(LOG, "formrdesc \"%s\": relid= =3D%u reltype=3D%u tdtypeid=3D%u",
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0rel= ationName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0TupleDescAttr(relation->rd_at= t, 0)->attrelid,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0relationReltype,
+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0relation->rd_att->tdtypeid);
+
=C2= =A0 =C2=A0 /*
=C2=A0 =C2=A0 =C2=A0* initialize tuple desc info
=C2=A0= =C2=A0 =C2=A0*/
@@ -4283,6 +4289,14 @@ RelationCacheInitializePhase3(vo= id)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* data correctly to = start with, because it may already have been
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0* copied into one or more catcache entries.)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 elog(LOG, "RelationCacheInitializePhase3 \"%s\": = relid=3D%u "
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"formrdesc tdtypeid=3D%u, pg_class reltype=3D%u%s",
+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RelationGetRelationName= (relation),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rel= ationGetRelid(relation),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0relation->rd_att->tdtypeid,
+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relp->reltype,
+ =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(relation->rd_att->tdtypeid !=3D re= lp->reltype)
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0? " MISMATCH" : "");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Assert(relation->rd_att->tdtypeid =3D=3D relp->relty= pe);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Assert(relation->rd_at= t->tdtypmod =3D=3D -1);

On an existing clus= ter with patched binaries it shows:
=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=A0 =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=A0 = =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=A0 =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=A0 =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=A0 =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=A0
= =C2=A0 formrdesc "pg_parameter_acl": relid=3D0 reltype=3D2173 tdt= ypeid=3D2173
=C2=A0 RelationCacheInitializePhase3 "pg_parameter_acl= ": relid=3D6243
=C2=A0 =C2=A0 formrdesc tdtypeid=3D2173, pg_class r= eltype=3D10097 MISMATCH

--
=

Mar= k Dilger
--00000000000035822d06502462b6--