BUG #18003: FATAL: cannot request additional shared memory outside shmem_request_hook

On 6/27/23 16:27, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 18003
Logged by: khaled ghazy
Email address: eng.khaledghazy@gmail.com
PostgreSQL version: 15.3
Operating system: Red Hat Enterprise Linux 8
Description:

Jun 27 23:21:18 hq-pgsql-test01 postmaster[1491680]: 2023-06-27 23:21:18.874
EEST [1491680] LOG: pgaudit extension initialized
Jun 27 23:21:18 hq-pgsql-test01 postmaster[1491680]: 2023-06-27 23:21:18.876
EEST [1491680] FATAL: cannot request additional shared memory outside
shmem_request_hook

What extensions are you loading after pgaudit?

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Hi,

On 2023-06-27 20:27:42 +0000, PG Bug reporting form wrote:

Jun 27 23:21:18 hq-pgsql-test01 postmaster[1491680]: 2023-06-27 23:21:18.874
EEST [1491680] LOG: pgaudit extension initialized
Jun 27 23:21:18 hq-pgsql-test01 postmaster[1491680]: 2023-06-27 23:21:18.876
EEST [1491680] FATAL: cannot request additional shared memory outside
shmem_request_hook

pgaudit prints "pgaudit extension initialized" at the end of _PG_init():
https://github.com/pgaudit/pgaudit/blob/master/pgaudit.c#L2254

So it's likely not pgaudit. What is shared_preload_libraries set to?

Unfortunately we only print library names after loading them, even at debug
level. But we do print information while searching libraries if you change
log_min_messages to debug3. Could you reproduce the issue with that and show
us the log messages?

That's not going to help you / the reporter, but to make issues like this
easier to debug in the future, I think we should

a) install an error context in load_libraries() printing the GUC name and
b) install an error context in internal_load_library() printing the name of
the shared library name

The reason for doing both a) and b) is that a) makes it easier to figure out
the cause of the library being loaded and b) would also work when the library
is loaded for a different reason, e.g. due to executing a function residing in
the library.

A bit surprised that we don't have that already.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

That's not going to help you / the reporter, but to make issues like this
easier to debug in the future, I think we should
a) install an error context in load_libraries() printing the GUC name and
b) install an error context in internal_load_library() printing the name of
the shared library name

+1. I'm not sure this specific issue justifies it, but it seems like that
might make it easier to diagnose other shared-library-load-time issues
as well.

regards, tom lane

Hi,

On 2023-06-27 17:44:57 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

That's not going to help you / the reporter, but to make issues like this
easier to debug in the future, I think we should
a) install an error context in load_libraries() printing the GUC name and
b) install an error context in internal_load_library() printing the name of
the shared library name

+1. I'm not sure this specific issue justifies it, but it seems like that
might make it easier to diagnose other shared-library-load-time issues
as well.

I started a separate thread on -hackers for that topic. See
/messages/by-id/20230628000307.rf6jnv4v4zyf6dqg@awork3.anarazel.de

Greetings,

Andres Freund