Re: BUG #16914: Regression test of the worker_spi fails if USE_MODULE_DB environment variable is set.

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2021-Mar-04, Michael Paquier wrote:
>> One problem with this solution is that this is not portable. Instead
>> of generating dynamically the configuration file, here is funkier
>> solution as we know that worker_spi would restart if the database it
>> should connect to does not exist: let's use a completely different
>> database name, not expected by any other modules. Then, this database
>> gets created in worker_spi.sql, with a reconnection to it.

> It's not that I *like* this solution, but let's say that I dislike it
> less than the other one. If there are no other ideas, I +1 this one.

The real problem here is that worker_spi illustrates a fundamentally
useless way to define which database a worker ought to connect to.
It's basically impossible for it to use anything except the hard-wired
default for the worker_spi.database GUC. You could wish that we could
fix it like

CREATE EXTENSION worker_spi;
+SELECT set_config('worker_spi.database', current_database(), false);
SELECT worker_spi_launch(4) IS NOT NULL;
-- wait until the worker completes its initialization

but that doesn't work because the session-local setting of the GUC won't
be seen over in the worker process.

Since the alleged point of this module is to be a prototype for
useful background workers, I think we should think of another way.
Maybe we need to work a bit harder on passing values from
worker_spi_launch to the worker, so that the DB name could be a
parameter to worker_spi_launch.

regards, tom lane