Re: background sessions
От | Robert Haas |
---|---|
Тема | Re: background sessions |
Дата | |
Msg-id | CA+TgmoYOfRRQmbv4_8n0Lwvv7kyF8OQg0Rq5_QNdeGhk-Sx5Dw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] background sessions (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Sat, Mar 18, 2017 at 1:10 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Mar 18, 2017 at 10:59 AM, Petr Jelinek > <petr.jelinek@2ndquadrant.com> wrote: >>> shm_redirect_to_shm_mq() wasn't really designed to be used this way; >>> it's designed for use by the worker, not the process that launched it. >>> If an error occurs while output is redirected, bad things will happen. >>> I think it would be better to find a way of sending that message to >>> the queue without doing this. >> >> Couldn't we just create special version of pq_endmessage that sends to >> shm_mq? > > Yes, I think that sounds good. > >>> Also, I suspect this is deadlock-prone. If we get stuck trying to >>> send a message to the background session while the queue is full, and >>> at the same time the session is stuck trying to send us a long error >>> message, we will have an undetected deadlock. That's why >>> pg_background() puts the string being passed to the worker into the >>> DSM segment in its entirety, rather than sending it through a shm_mq. >> >> Yeah I think this will need to use the nowait = true when sending to >> shm_mq and chunk the message if necessary... > > Hmm, yeah. If you take breaks while sending to check for data that > you need to receive, then you should be fine. So is this patch going anywhere? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: