Re: Spawned Background Process Knows the Exit of Client Process?
От | Ashutosh Bapat |
---|---|
Тема | Re: Spawned Background Process Knows the Exit of Client Process? |
Дата | |
Msg-id | CAExHW5vhK2FcXdXBKTU5OO9Qh_+3eZM70AAAMhJarckrsoEK2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Spawned Background Process Knows the Exit of Client Process? (Shichao Jin <jsc0218@gmail.com>) |
Ответы |
Re: Spawned Background Process Knows the Exit of Client Process?
|
Список | pgsql-hackers |
On Fri, May 15, 2020 at 11:53 PM Shichao Jin <jsc0218@gmail.com> wrote: > > Hi Postgres Hackers, > > I am wondering is there any elegant way for self-spawned background process (forked by us) to get notified when the regularclient-connected process exit from the current database (switch db or even terminate)? > > The background is that we are integrating a thread-model based storage engine into Postgres via foreign data wrapper. PostgreSQL now support pluggable storage API. Have you considered using that instead of FDW? > The engine is not allowed to have multiple processes to access it. So we have to spawn a background process to access theengine, while the client process can communicate with the spawned process via shared memory. In order to let the enginerecognize the data type in Postgres, the spawned process has to access catalog such as relcache, and It must connectto the target database via BackgroundWorkerInitializeConnection to get the info. Unfortunately, it is not possibleto switch databases for background process. So it has to get notified when client process switches db or terminate,then we can correspondingly close the spawned process. Please advise us if there are alternative approaches. There can be multiple backends accessing different database. But from your description it looks like there is only one background process that will access the storage engine and it will be shared by multiple backends which may be connected to different databases. If that's correct, you will need to make that background process independent of database and just access storage. That looks less performance though. May be you can elaborate more about your usecase. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: