shm_mq inconsistent behavior of SHM_MQ_DETACHED

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: shm_mq inconsistent behavior of SHM_MQ_DETACHED
Date: 2014-04-22 13:55:00
Message-ID: 535674B4.2040706@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I was playing with shm_mq and found a little odd behavior with detaching
after sending messages.

Following sequence behaves as expected (receiver gets 2 messages):
P1 -> set_sender
P1 -> attach
P2 -> set_receiver
P2 -> attach
P1 -> send
P2 -> receive
P1 -> send
P1 -> detach
P2 -> receive
P2 -> detach

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.

The reason for this behavior is that mqh_counterparty_attached is only
set by shm_mq_receive. This does not seem to be consistent - I would
either expect to get SHM_MQ_DETACHED always when other party has
detached or always get all remaining messages that are in queue (and I
would strongly prefer the latter).

Maybe the shm_mq_get_bytes_written should be used to determine if there
is something left for us to read in the receiver if we hit the
!mqh_counterparty_attached code path with detached sender?

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-22 14:11:17 Re: Store data in pg_toast for custom type fails (bug?)
Previous Message Simon Riggs 2014-04-22 13:45:27 Re: AXLE Plans for 9.5 and 9.6