On Mon, Aug 21, 2017 at 10:07 AM, Craig Ringer wrote:
> Makes sense, and I'm not especially concerned. If the expected solution to
> such usage is to use non-blocking calls, that's fine with me.
>
> I partly wanted to put this out there to help the next person looking into
> it. Or myself, when I'
On 21 August 2017 at 21:44, Robert Haas wrote:
> While this would work, I don't really see the need for it given the
> availability of nonblocking operations. See mq_putmessage() for an
> example.
>
Makes sense, and I'm not especially concerned. If the expected solution to
such usage is to use
On Sun, Aug 20, 2017 at 10:57 PM, Craig Ringer wrote:
> I've noticed a possible bug / design limitation where shm_mq_wait_internal
> sleep in a latch wait forever, and the postmaster gets stuck waiting for the
> bgworker the wait is running in to exit.
>
> This happens when the shm_mq does not hav
On 21 August 2017 at 10:57, Craig Ringer wrote:
> Hi all
>
> I've noticed a possible bug / design limitation where shm_mq_wait_internal
> sleep in a latch wait forever, and the postmaster gets stuck waiting for
> the bgworker the wait is running in to exit.
>
> This happens when the shm_mq does n
Hi all
I've noticed a possible bug / design limitation where shm_mq_wait_internal
sleep in a latch wait forever, and the postmaster gets stuck waiting for
the bgworker the wait is running in to exit.
This happens when the shm_mq does not have an associated bgworker handle
registered because the o
