Re: background sessions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: background sessions
Date
Msg-id CA+TgmoYOfRRQmbv4_8n0Lwvv7kyF8OQg0Rq5_QNdeGhk-Sx5Dw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] background sessions  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel Append implementation
Next
From: Craig Ringer
Date:
Subject: Re: Logical decoding on standby