BackgroundWorkerInitializeConnection(NULL, ...) doesn't work

From: Andrew Tipton <andrew(at)kiwidrew(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: BackgroundWorkerInitializeConnection(NULL, ...) doesn't work
Date: 2013-08-10 13:24:16
Message-ID: CA+M2pVU4GoHW2wwvE1jd32pYKYwXUpEuT=s1Ji7YAgnLFFARzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-08-10 14:03:26 Re: proposal: lob conversion functionality
Previous Message Tatsuo Ishii 2013-08-10 12:07:13 Re: killing pg_dump leaves backend process