Potential issue in listExtensions()

Started by Suraj Kharage7 months ago4 messages
#1Suraj Kharage
suraj.kharage@enterprisedb.com
1 attachment(s)

Hi,

Upstream commit d696406a9b255546bc1716d07199103abd8bb785 [1]/messages/by-id/CABUevEyTMyXC6OvCWkj+rPnHrfi8_Rw_+DD_jzgFFNPqgf+Oig@mail.gmail.com -- added the
support for default extension version in \dx output and changed the query
that fetches the extension list.
The changed query seems problematic and might display duplicate entries of
extension if the same object oid exists in pg_description.

If I understand correctly, after oid wraparound, it is possible that the
existing oid from another catalog might be used again for other catalog
objects as per GetNewOidWithIndex().
If this is true, then it is possible that oid exists in pg_description for
an object will be used for extension oid, and we might get a duplicate
entry in \dx output.

```

*"FROM pg_catalog.pg_extension e " "LEFT JOIN pg_catalog.pg_namespace n ON
n.oid = e.extnamespace " "LEFT JOIN pg_catalog.pg_description d ON
d.objoid = e.oid " "LEFT JOIN pg_catalog.pg_available_extensions()
ae(name, default_version, comment) ON ae.name <http://ae.name&gt; = e.extname
" "AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass\n",*
```

We may need to handle this by moving the AND condition to the left join for
pg_catalog.pg_description, so that we retrieve only pg_extension entries
from pg_description.
Attaching the patch for the same.

Thoughts?

[1]: /messages/by-id/CABUevEyTMyXC6OvCWkj+rPnHrfi8_Rw_+DD_jzgFFNPqgf+Oig@mail.gmail.com --
/messages/by-id/CABUevEyTMyXC6OvCWkj+rPnHrfi8_Rw_+DD_jzgFFNPqgf+Oig@mail.gmail.com
--

Thanks & Regards,
Suraj kharage,

enterprisedb.com <https://www.enterprisedb.com/&gt;

Attachments:

Fix_list_extensions.patchapplication/octet-stream; name=Fix_list_extensions.patchDownload
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 1d08268393e..24e0100c9f0 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -6188,8 +6188,8 @@ listExtensions(const char *pattern)
 					  "FROM pg_catalog.pg_extension e "
 					  "LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace "
 					  "LEFT JOIN pg_catalog.pg_description d ON d.objoid = e.oid "
-					  "LEFT JOIN pg_catalog.pg_available_extensions() ae(name, default_version, comment) ON ae.name = e.extname "
-					  "AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass\n",
+					  "AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass "
+					  "LEFT JOIN pg_catalog.pg_available_extensions() ae(name, default_version, comment) ON ae.name = e.extname\n",
 					  gettext_noop("Name"),
 					  gettext_noop("Version"),
 					  gettext_noop("Default version"),
#2Dilip Kumar
dilipbalaut@gmail.com
In reply to: Suraj Kharage (#1)
Re: Potential issue in listExtensions()

On Thu, Jun 5, 2025 at 5:53 AM Suraj Kharage
<suraj.kharage@enterprisedb.com> wrote:

Hi,

Upstream commit d696406a9b255546bc1716d07199103abd8bb785 [1] added the support for default extension version in \dx output and changed the query that fetches the extension list.
The changed query seems problematic and might display duplicate entries of extension if the same object oid exists in pg_description.

If I understand correctly, after oid wraparound, it is possible that the existing oid from another catalog might be used again for other catalog objects as per GetNewOidWithIndex().
If this is true, then it is possible that oid exists in pg_description for an object will be used for extension oid, and we might get a duplicate entry in \dx output.

Yes your understanding is correct and there is a possibility of the
bug you mentioned.

```
"FROM pg_catalog.pg_extension e "
"LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace "
"LEFT JOIN pg_catalog.pg_description d ON d.objoid = e.oid "
"LEFT JOIN pg_catalog.pg_available_extensions() ae(name, default_version, comment) ON ae.name = e.extname "
"AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass\n",
```

We may need to handle this by moving the AND condition to the left join for pg_catalog.pg_description, so that we retrieve only pg_extension entries from pg_description.
Attaching the patch for the same.

Thoughts?

Attached patch seems to be fixing the issue.

--
Regards,
Dilip Kumar
Google

#3Magnus Hagander
magnus@hagander.net
In reply to: Dilip Kumar (#2)
Re: Potential issue in listExtensions()

On Thu, Jun 5, 2025 at 9:50 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:

On Thu, Jun 5, 2025 at 5:53 AM Suraj Kharage
<suraj.kharage@enterprisedb.com> wrote:

Hi,

Upstream commit d696406a9b255546bc1716d07199103abd8bb785 [1] added the

support for default extension version in \dx output and changed the query
that fetches the extension list.

The changed query seems problematic and might display duplicate entries

of extension if the same object oid exists in pg_description.

If I understand correctly, after oid wraparound, it is possible that the

existing oid from another catalog might be used again for other catalog
objects as per GetNewOidWithIndex().

If this is true, then it is possible that oid exists in pg_description

for an object will be used for extension oid, and we might get a duplicate
entry in \dx output.

Yes your understanding is correct and there is a possibility of the
bug you mentioned.

Yup, agreed. Simply, the new LEFT JOIN was added on the wrong line.

```

"FROM pg_catalog.pg_extension e "
"LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace "
"LEFT JOIN pg_catalog.pg_description d ON d.objoid = e.oid "
"LEFT JOIN pg_catalog.pg_available_extensions() ae(name,

default_version, comment) ON ae.name = e.extname "

"AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass\n",
```

We may need to handle this by moving the AND condition to the left join

for pg_catalog.pg_description, so that we retrieve only pg_extension
entries from pg_description.

Attaching the patch for the same.

Thoughts?

Attached patch seems to be fixing the issue.

LGTM as well, applied.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#4Suraj Kharage
suraj.kharage@enterprisedb.com
In reply to: Magnus Hagander (#3)
Re: Potential issue in listExtensions()

Thanks, Magnus and Dilip.
--

Thanks & Regards,
Suraj kharage,

enterprisedb.com <https://www.enterprisedb.com/&gt;

On Thu, Jun 5, 2025 at 1:34 PM Magnus Hagander <magnus@hagander.net> wrote:

Show quoted text

On Thu, Jun 5, 2025 at 9:50 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:

On Thu, Jun 5, 2025 at 5:53 AM Suraj Kharage
<suraj.kharage@enterprisedb.com> wrote:

Hi,

Upstream commit d696406a9b255546bc1716d07199103abd8bb785 [1] added the

support for default extension version in \dx output and changed the query
that fetches the extension list.

The changed query seems problematic and might display duplicate entries

of extension if the same object oid exists in pg_description.

If I understand correctly, after oid wraparound, it is possible that

the existing oid from another catalog might be used again for other catalog
objects as per GetNewOidWithIndex().

If this is true, then it is possible that oid exists in pg_description

for an object will be used for extension oid, and we might get a duplicate
entry in \dx output.

Yes your understanding is correct and there is a possibility of the
bug you mentioned.

Yup, agreed. Simply, the new LEFT JOIN was added on the wrong line.

```

"FROM pg_catalog.pg_extension e "
"LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace "
"LEFT JOIN pg_catalog.pg_description d ON d.objoid = e.oid "
"LEFT JOIN pg_catalog.pg_available_extensions() ae(name,

default_version, comment) ON ae.name = e.extname "

"AND d.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass\n",
```

We may need to handle this by moving the AND condition to the left join

for pg_catalog.pg_description, so that we retrieve only pg_extension
entries from pg_description.

Attaching the patch for the same.

Thoughts?

Attached patch seems to be fixing the issue.

LGTM as well, applied.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;