Re: Inconsistent bgworker behaviour

Поиск
Список
Период
Сортировка
От Beena Emerson
Тема Re: Inconsistent bgworker behaviour
Дата
Msg-id CAOG9ApGgfDRBpxPg90SBzTYDLvQh7wfDgebhN2ht-2gNVnuqRA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inconsistent bgworker behaviour  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: Inconsistent bgworker behaviour  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-general

Hello,

Thank you for your reply.

> We could probably use a WaitForBackgroundWorkerTermination(...) to
> correspond to WaitForBackgroundWorkerStartup(...) .
>
> I think you'll probably want to GetBackgroundWorkerPid(...) and examine
> the returned BgwHandleStatus to see if it's BGWH_STOPPED . If not, keep
> waiting. You might want a timeout to re-check.

I have tried checking the status but I found that BGWH_STOPPED does not imply that the background worker has unregistered.

I updated the code as suggested  to check the Handle status in a loop and added appropriate LOG messages to understand the flow.

This is the log output. The old M.datatbases value was "db1, db4".

LOG:  received SIGHUP, reloading configuration files
LOG:  parameter "m.databases" changed to "db1, db2"
LOG:  WaitLatch Ends
LOG:  The bgworker status is BGWH_STOPPED
WARNING:  could not register background process for database "db2"
HINT:  You may need to increase configuration parameter "max_worker_processes".
LOG:  worker process: m db4 (PID 8629) exited with exit code 0
LOG:  unregistering background worker "m db4"
server signaled

As seen even though the status is BGWH_STOPPED, the slot is not free and hence the new worker cannot be launched.

Is there any way to check if the bgworker has unregistered and freed a slot?

Thanks,

Beena

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

Предыдущее
От: avpro avpro
Дата:
Сообщение: partial text search
Следующее
От: Andrey Lizenko
Дата:
Сообщение: Re: How to monitor locks (max_pred_locks_per_transaction)?