pgsql: Clarify the checks in RegisterBackgroundWorker.

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема pgsql: Clarify the checks in RegisterBackgroundWorker.
Дата
Msg-id E1qpm0G-000lff-O8@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Clarify the checks in RegisterBackgroundWorker.

In EXEC_BACKEND or single-user mode, we process
shared_preload_libraries at postmaster startup as usual, but also at
backend startup. When a library calls RegisterBackgroundWorker() when
being loaded into a backend process, we go through the motions to add
the worker to BackgroundWorkerList, even though that is a
postmaster-private data structure. Make it return early when called in
a backend process, without changing BackgroundWorkerList.

You could argue that it was intentional: In non-EXEC_BACKEND mode, the
backend processes inherit BackgroundWorkerList at fork(), so it does
make some sense to initialize it to the same state in EXEC_BACKEND
mode, too. It's clearly a postmaster-private structure, though, and
all the functions that use it are clearly marked as "should only be
called in postmaster".

You could also argue that libraries should not call
RegisterBackgroundWorker() during backend startup. It's too late to
correctly register any static background workers at that stage. But
it's a common pattern in extensions, and it doesn't seem worth the
churn to require all extensions to change it.

Another sloppiness was the exception for "internal" background
workers. We checked that RegisterBackgroundWorker() was called during
shared_preload_libraries processing, or the background worker was an
internal one. That exception was made in commit 665d1fad99 to allow
postmaster to register the logical apply launcher in
ApplyLauncherRegister(). The way the check was written, it would not
complain if you registered an internal background worker in a regular
backend process. But it would complain if postmaster registered a
background worker defined in a shared library, outside
shared_preload_libraries processing. I think the correct rule is that
you can only register static background workers in the postmaster
process, and only before the bgworker shared memory array has been
initialized. Check for that more directly.

Reviewed-by: Thomas Munro
Discussion: https://www.postgresql.org/message-id/4f95c1fc-ad3c-7974-3a8c-6faa3931804c@iki.fi

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/1ca312686e4c4b270cb598429983a07c73a5c44a

Modified Files
--------------
src/backend/postmaster/bgworker.c | 44 +++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 11 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: pgsql: Optimize various aggregate deserialization functions
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Doc: use CURRENT_USER not USER in plpgsql trigger examples.