BackgroundWorkerInitializeConnection(NULL, ...) doesn't work - Mailing list pgsql-hackers

From Andrew Tipton
Subject BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
Date
Msg-id CA+M2pVU4GoHW2wwvE1jd32pYKYwXUpEuT=s1Ji7YAgnLFFARzA@mail.gmail.com
Whole thread Raw
Responses Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
The documentation for 9.4 says, in the "Background Worker Processes" section:

Once running, the process can connect to a database by calling BackgroundWorkerInitializeConnection(char *dbname, char *username). This allows the process to run transactions and queries using the SPI interface. If dbname is NULL, the session is not connected to any particular database, but shared catalogs can be accessed. If username is NULL, the process will run as the superuser created during initdb.

However, should one attempt to pass NULL for the dbname parameter, the process will die with:

FATAL: database 0 does not exist

BackgroundWorkerInitializeConnection() is essentially just a wrapper around InitPostgres(), passing it the supplied dbname and username.  (And passing InvalidOid for the dboid parameter.)  When InitPostgres() finds that dbname is null, it falls back on dboid.  GetDatabaseTupleByOid() returns NULL when given InvalidOid, resulting in the aforementioned elog(FATAL).

Based on my quick read through InitPostgres() and postinit.c, it's not even clear that there's a way to access the shared catalogs without connecting to a specific database.  Certainly the rest of the code in InitPostgres expects MyDatabaseId to be set to something useful.


Regards,
Andrew Tipton

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: killing pg_dump leaves backend process
Next
From: Tom Lane
Date:
Subject: Re: proposal: lob conversion functionality