Content-Type: multipart/alternative;
 boundary="------------RT0YfPq3y6eDsZliE5m0pqsH"
Message-ID: <13310e0b-e2b0-45a2-873d-e2b51a8ea3b4@dunslane.net>
Date: Sun, 26 Apr 2026 10:50:10 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix a server crash problem from pg_get_database_ddl
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Chao Li <li.evan.chao@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Japin Li <japinli@hotmail.com>
References: <573E45C1-31A4-4885-A00C-1A2171159A2A@gmail.com>
 <28b82ab2-5721-4e7c-bf71-979c3f198a2e@app.fastmail.com>
 <SY7PR01MB109214566B069E9C9084590FEB6232@SY7PR01MB10921.ausprd01.prod.outlook.com>
 <634F4A5D-9D38-4F9D-BC1C-70815CBB5089@gmail.com>
 <CAHg+QDcNyJ94cCD+9ZRfz==hDnghjE5BaR4+BiSWXt82hpgDtA@mail.gmail.com>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAlwQTAQgAQQIbAwIX
 gAIZAQULCQgHAwUVCgkICwUWAgMBAAIeBRYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNGd
 BQkdEO8nAAoJEJn6f8tZ/DuBq74H/jkTR4Zi3stbw+xC7v2u3QozssK7MYPL2AsVfh7OealS
 h182fiWXpfvmmAB7WUHbhk9GC2RAOnHI/2d2jgKaMLAHsGYOT0YopTVIwRY43fCw/mK67yxc
 wmDcX+zyKfLaivNbf5A7QPLNwda98bEAMSJ8Sn652Uc6cA8t3uKGsVzbRBQOoYzjgvBCfSrE
 9ql3PDNg0l4BfAqabd2f70ZUm9VAMEPrgv/v2xI7M2XiL4g5BVmqLCOwxLM8RMCotCuoweUr
 VO43DeBCIDwLxotMJKvGWDjBzQYlU1NPUAtNcz/gN9ITUe1VUGjyvGj4u1lxBOcQQUw7l1+T
 5moZ4iZxXzvOwE0ETspYWQEIANGc4zQULOxhbqO2dyD51YhqCNRmm9oKWaqf+wmW4tpDe/VV
 cxAnNizd4LWCHfzpb5cHAtGkOPePMfzWVf6nvdF7d3eglbtf59+zG7O7llV0xSSoFiieQBsr
 GvqDInXYX/4mRRXMtyhM353/tixC9RWLs1oofyYmCPPXXY7h9R7en3B8BoVrRFcdzlIY/NFN
 hFGW/9dkEiGjgna2Rk6e15kln4ZvFBWUg23p93w/pqXcxY6+k/8TEk+C4R+M6w7o2PLGOjdZ
 +kPiUcw5H85zf/yZJwQXzisXaNduwWB6Vads9YC9dj6kPR1c4VGRqAaYL++LAEOqrlvm2Tvq
 QqZRtnEAEQEAAcLAfAQYAQgAJgIbDBYhBOQ+WEYd/Hy/RGkVpZn6f8tZ/DuBBQJoGNI2BQkd
 EODdAAoJEJn6f8tZ/DuBfw0IAKTsfD40teP/pp+bsLLMSxPXUYrrprTj7WFB5v61p6dkpSr/
 qXmMlyahdxQFaPmfVgVirB1Vk/kHiWNnnGjfUV9nB2Zg9LI0Xb9/ts3LsUiRWXzG3tkMY6XL
 vsVOxW4XFRND9l2q+WW93aZ1DZl+fqWfYgMvsusFRhmGFOKTRfKPta2Pkv+AhA24N4+PrR5p
 bU4k2MO8PAGiK8eaYKGFG1bHKuAvoDoF7WXJ3FHxuWqLnKEt4dfOLm5pAe3zq1Lt6q8azT9i
 QWGpSAK5vQUWQHBHpiDjdPeqKZ6HiAXIIKfSmb+jrvXBqoP+D6/K7rUjG2aXiRtTIAXms9sm
 VRu7cmw=
In-Reply-To: 
 <CAHg+QDcNyJ94cCD+9ZRfz==hDnghjE5BaR4+BiSWXt82hpgDtA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/13310e0b-e2b0-45a2-873d-e2b51a8ea3b4%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------RT0YfPq3y6eDsZliE5m0pqsH
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 2026-04-23 Th 2:47 AM, SATYANARAYANA NARLAPURAM wrote:
>
>
>
>     Thanks for printing out that. Yes, they are similar.
>
>     I agree with what Tom said in [2]:
>     ```
>     This is not a bug. This is a superuser intentionally breaking
>     the system by corrupting the catalogs. There are any number
>     of ways to cause trouble with ill-advised manual updates to a
>     catalog table. Try, eg, "DELETE FROM pg_proc" (... but not in
>     a database you care about).
>     ```
>
>     So, let me take back this patch.
>
>     [2]
>     https://www.postgresql.org/message-id/1538113.1768921841@sss.pgh.pa.us
>
>
> In this case, it is a very corner case but not something superuser 
> intentionally breaks.
> For example, a concurrent tablespace drop + database ddl to assign a 
> different tablespace or default.
> We aren't acquiring Access Share lock on the DB in this function 
> (intentional) so it is a good practice
> to do the null checks. Of course, it makes more sense to add this 
> comment while doing a code review.
> I will let Tom and others chime in with their thoughts on fixing this.
>
> Attached an injection point test to show the race. Not intended to commit.
>
>

I agree if there's a race condition we should protect against it. I 
don't much like the idea of silently ignoring it, though. Raising an 
error seems more like the right thing to do.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------RT0YfPq3y6eDsZliE5m0pqsH
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2026-04-23 Th 2:47 AM, SATYANARAYANA
      NARLAPURAM wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHg+QDcNyJ94cCD+9ZRfz==hDnghjE5BaR4+BiSWXt82hpgDtA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
            <br>
            Thanks for printing out that. Yes, they are similar.<br>
            <br>
            I agree with what Tom said in [2]:<br>
            ```<br>
            This is not a bug. This is a superuser intentionally
            breaking<br>
            the system by corrupting the catalogs. There are any number<br>
            of ways to cause trouble with ill-advised manual updates to
            a<br>
            catalog table. Try, eg, "DELETE FROM pg_proc" (... but not
            in<br>
            a database you care about).<br>
            ```<br>
            <br>
            So, let me take back this patch.<br>
            <br>
            [2] <a
href="https://www.postgresql.org/message-id/1538113.1768921841@sss.pgh.pa.us"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://www.postgresql.org/message-id/1538113.1768921841@sss.pgh.pa.us</a></blockquote>
          <div><br>
          </div>
          <div>In this case, it is a very corner case but not something
            superuser intentionally breaks.</div>
          <div>For example, a concurrent tablespace drop + database ddl
            to assign a different tablespace or default.</div>
          <div>We aren't acquiring Access Share lock on the DB in this
            function (intentional) so it is a good practice</div>
          <div>to do the null checks. Of course, it makes more sense to
            add this comment while doing a code review.</div>
          <div>I will let Tom and others chime in with their thoughts on
            fixing this.</div>
          <div><br>
          </div>
          <div>Attached an injection point test to show the race. Not
            intended to commit.</div>
          <div><br>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>I agree if there's a race condition we should protect against it.
      I don't much like the idea of silently ignoring it, though.
      Raising an error seems more like the right thing to do.</p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <pre class="moz-signature"
    signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------RT0YfPq3y6eDsZliE5m0pqsH--