Re: Database disconnection and switch inside a single bgworker - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Database disconnection and switch inside a single bgworker
Date
Msg-id 22285.1384528483@sss.pgh.pa.us
Whole thread Raw
In response to Database disconnection and switch inside a single bgworker  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Database disconnection and switch inside a single bgworker  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> Currently, bgworkers offer the possibility to connect to a given
> database using BackgroundWorkerInitializeConnection in bgworker.h, but
> there is actually no way to disconnect from a given database inside
> the same bgworker process.

That's isomorphic to having a backend switch to a different database,
which occasionally gets requested, but there is no real likelihood
that we'll ever implement.  The problem is, how can you be sure you
have flushed all the database-specific state that's been built up?
The relcache and catcaches are only the tip of the iceberg; we've
got caches all over the place.  And once you had flushed that data,
you'd have to recreate it --- but the code for doing so is intimately
intertwined with connection startup tasks that you'd most likely not
want to repeat.

And, once you'd done all that work, what would you have?  A database
switch methodology that would save a fork(), but not much else.
The time to warm up the caches wouldn't be any better than in a
fresh process.

The cost/benefit ratio for making this work just doesn't look very
promising.  That's why autovacuum is built the way it is.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: strncpy is not a safe version of strcpy
Next
From: Rod Taylor
Date:
Subject: Re: GIN improvements part2: fast scan