Message-ID: <535EB91B.1040908@2ndquadrant.com>
Date: Mon, 28 Apr 2014 22:24:59 +0200
From: Petr Jelinek <petr@2ndquadrant.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: shm_mq inconsistent behavior of SHM_MQ_DETACHED
References: <535674B4.2040706@2ndquadrant.com>
 <CA+TgmoY3SF4d3tPa5wix1O4X-9viJ+fGz0ZpJX1=jYCW_2TQOg@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoY3SF4d3tPa5wix1O4X-9viJ+fGz0ZpJX1=jYCW_2TQOg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 28/04/14 15:36, Robert Haas wrote:
> On Tue, Apr 22, 2014 at 9:55 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>>
>> But if I do first receive after detach like in this sequence:
>> P1 -> set_sender
>> P1 -> attach
>> P2 -> set_receiver
>> P2 -> attach
>> P1 -> send
>> P1 -> send
>> P1 -> detach
>> P2 -> receive
>>
>> I get SHM_MQ_DETACHED on the receiver even though there are messages in the
>> ring buffer.
>
> That's a bug.
>
> I'm thinking that the problem is really revolves around
> shm_mq_wait_internal().  It returns true if the queue is attached but
> not detached, and false if either the detach has already happened, or
> if we establish via the background worker handle that it will never
> come.  But in the case of receiving, we want to treat
> attached-then-detached as a success case, not a failure case.
>
> Can you see if the attached patch fixes it?
>


Yes, the patch fixes it for me.


-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers