database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00
Code Activity

Process session_preload_libraries within InitPostgres's transaction.

Browse Source 
Previously we did this after InitPostgres, at a somewhat randomly chosen
place within PostgresMain.  However, since commit a0ffa885e doing this
outside a transaction can cause a crash, if we need to check permissions
while replacing a placeholder GUC.  (Besides which, a preloaded library
could itself want to do database access within _PG_init.)

To avoid needing an additional transaction start/end in every session,
move the process_session_preload_libraries call to within InitPostgres's
transaction.  That requires teaching the code not to call it when
InitPostgres is called from somewhere other than PostgresMain, since
we don't want session_preload_libraries to affect background workers.
The most future-proof solution here seems to be to add an additional
flag parameter to InitPostgres; fortunately, we're not yet very worried
about API stability for v15.

Doing this also exposed the fact that we're currently honoring
session_preload_libraries in walsenders, even those not connected to
any database.  This seems, at minimum, a POLA violation: walsenders
are not interactive sessions.  Let's stop doing that.

(All these comments also apply to local_preload_libraries, of course.)

Per report from Gurjeet Singh (thanks also to Nathan Bossart and Kyotaro
Horiguchi for review).  Backpatch to v15 where a0ffa885e came in.

Discussion: https://postgr.es/m/CABwTF4VEpwTHhRQ+q5MiC5ucngN-whN-PdcKeufX7eLSoAfbZA@mail.gmail.com
This commit is contained in:
Tom Lane
2022-07-25 10:27:43 -04:00
parent 19f82323db
commit 31ed3cf746
6 changed files with 64 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
src/backend/utils/init/postinit.c
View File

@ -622,29 +622,48 @@ BaseInit(void)
* InitPostgres
* Initialize POSTGRES.
*
* Parameters:
* in_dbname, dboid: specify database to connect to, as described below
* username, useroid: specify role to connect as, as described below
* load_session_libraries: TRUE to honor [session|local]_preload_libraries
* override_allow_connections: TRUE to connect despite !datallowconn
* out_dbname: optional output parameter, see below; pass NULL if not used
*
* The database can be specified by name, using the in_dbname parameter, or by
* OID, using the dboid parameter. In the latter case, the actual database
* OID, using the dboid parameter. Specify NULL or InvalidOid respectively
* for the unused parameter. If dboid is provided, the actual database
* name can be returned to the caller in out_dbname. If out_dbname isn't
* NULL, it must point to a buffer of size NAMEDATALEN.
*
* Similarly, the username can be passed by name, using the username parameter,
* Similarly, the role can be passed by name, using the username parameter,
* or by OID using the useroid parameter.
*
* In bootstrap mode no parameters are used. The autovacuum launcher process
* doesn't use any parameters either, because it only goes far enough to be
* able to read pg_database; it doesn't connect to any particular database.
* In walsender mode only username is used.
* In bootstrap mode the database and username parameters are NULL/InvalidOid.
* The autovacuum launcher process doesn't specify these parameters either,
* because it only goes far enough to be able to read pg_database; it doesn't
* connect to any particular database. An autovacuum worker specifies a
* database but not a username; conversely, a physical walsender specifies
* username but not database.
*
* As of PostgreSQL 8.2, we expect InitProcess() was already called, so we
* already have a PGPROC struct ... but it's not completely filled in yet.
* By convention, load_session_libraries should be passed as true in
* "interactive" sessions (including standalone backends), but false in
* background processes such as autovacuum. Note in particular that it
* shouldn't be true in parallel worker processes; those have another
* mechanism for replicating their leader's set of loaded libraries.
*
* We expect that InitProcess() was already called, so we already have a
* PGPROC struct ... but it's not completely filled in yet.
*
* Note:
* Be very careful with the order of calls in the InitPostgres function.
* --------------------------------
*/
void
InitPostgres(const char *in_dbname, Oid dboid, const char *username,
Oid useroid, char *out_dbname, bool override_allow_connections)
InitPostgres(const char *in_dbname, Oid dboid,
const char *username, Oid useroid,
bool load_session_libraries,
bool override_allow_connections,
char *out_dbname)
{
bool bootstrap = IsBootstrapProcessingMode();
bool am_superuser;
@ -1108,6 +1127,16 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
/* Initialize this backend's session state. */
InitializeSession();
/*
* If this is an interactive session, load any libraries that should be
* preloaded at backend start. Since those are determined by GUCs, this
* can't happen until GUC settings are complete, but we want it to happen
* during the initial transaction in case anything that requires database
* access needs to be done.
*/
if (load_session_libraries)
process_session_preload_libraries();
/* report this backend in the PgBackendStatus array */
if (!bootstrap)
pgstat_bestart();