On 2026-May-20, Antonin Houska wrote: > Alvaro Herrera <[email protected]> wrote:
> The call of shm_mq_detach() got lost, or do you rely on dsm_detach() to call > shm_mq_detach_callback() ? The latter does not free ->mqh_buffer. Hmm, this I think this is a code documentation bug then, because the comment for shm_mq_attach() says * If seg != NULL, the queue will be automatically detached when that dynamic * shared memory segment is detached. I think it's strange, or buggy even, to say that "the queue is automatically detached", but that you still have to call dsm_mq_detach() afterwards. I can put back the shm_mq_detach() call, of course. > + * Now detach from our shared memory segment. In error cases there > might > + * still be messages from the worker in the queue, which > ProcessInterrupts > + * would try to read; this is pointless (and causes an assertion > failure), > + * so set the global pointer to NULL to have ProcessRepackMessages > ignore > + * them. > I suppose the reason for the assertion failure was reading from the queue > after the backend had detached from it? Thanks for fixing that. Yeah, that's exactly what happened. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La vida es para el que se aventura"
