On Mon, Aug 12, 2013 at 1:26 AM, Michael Paquier wrote:
While playing a bit with background workers (commit 527ea66), I found that
setting bgw_main for a dynamic bgworker, as well as bgw_library_name and
bgw_library_name, crashes to server if the library defining the function
defined in bgw_main is not loaded.
Yep. As the documentation says: "bgw_main may be NULL; in that case,
bgw_library_name and bgw_function_name will be used to determine the
entrypoint. This is useful for background workers launched after
postmaster startup, where the postmaster does not have the requisite
library loaded."

Wouldn't be clearer for the user to add a new flag in
BackgroundWorker:bgworker.h to define a class of bgworker? Or at least
specify clearly in the docs just to never set bgw_main if the library is not
loaded previously using for example shared_preload_libraries?
I don't think adding a flag really eliminates any possibility for user
confusion that doesn't already exist as things stand. However,
changing the documentation might make sense. The key point is that if
the function must be loaded into both the registering backend and the
worker backend, and it must also be loaded into both backends *at the
same address*. Anything that's loaded later than
shared_preload_libraries isn't likely to be soon enough, and even if
you do load the library at shared_preload_libraries time, I'm not
clear that it's going to work reliably in an EXEC_BACKEND environment.
  What if the OS uses ASLR and puts the shared library at different
addresses in different child processes? It'll crash, that's what.

It's almost tempting to tell people "don't use bgw_main", but I think
that might be going overboard. This is expert-level hackery; experts
don't usually like being told what to do without being told why they

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
grouppgsql-hackers @
postedAug 12, '13 at 5:26a
activeAug 16, '13 at 6:20p

2 users in discussion

Michael Paquier: 1 post Robert Haas: 1 post



site design / logo © 2017 Grokbase