Feature:: Function to run queries in the background without being attached to a session.

[knizhnik]

If pg_background_launch function is called from non-interactive session, i.e.
psql -c "pg_background_launch(...)" then pg_background is failed with "Unable to map dynamic shared memory segment" message. It happens because dynamic shared memory segment is already destroyed by terminated backend. dsm_pin_mapping is not able to prevent it, because it is not incrementing reference counter. The problem can be solved by using dsm_pin_segment, but correspondent dsm_unpin_segment is available only in Postgres 10.

I wonder if there are plans to port pg_background to 10 (it requires minimal efforts: specify background worker function not by address but by name) and is it better to use pin/unpin segment to let background worker correctly start even if host backend already terminates.

[vibhorkum]

Yeah. Since Postgres 10 still in beta, therefore I haven't changed the code. I will update the module later as V10 get released.

[danigosa]

@vibhorkum any new on this? It's already PG10.1 and we having still this issue :(

[vibhorkum]

Right now. I am not working on this. This is really not an issue/bug with pg_background. It is a feature enhancement. So will look into this as I get time

[vibhorkum]

Renaming the title of the thread. This is a feature request.

[rjuju]

@knizhnik but if we use dsm_pin_segment() we might leak the dynamic shared memory permanently if there's any problem while launching the dynamic bgworker and/or if the calling backend query is canceled right? I guess that we could work around any problem (such as a query cancel) with a PG_TRY / PG_CATCH block in the backend, but I don't see how we could detect something happening in the dynamic bgworker before it has a chance to unping the segment.