Feedback-ID: ie3de48e3:Fastmail
Date: Wed, 20 May 2026 13:13:43 -0700
From: Alvaro Herrera <alvherre@kurilemu.de>
To: Antonin Houska <ah@cybertec.at>
Cc: Baji Shaik <baji.pgdev@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Fix REPACK decoding worker not cleaned up on FATAL exit
Message-ID: <ag4UgRynWPeirLnJ@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8656.1779263646@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/ag4UgRynWPeirLnJ%40alvherre.pgsql>
Precedence: bulk

On 2026-May-20, Antonin Houska wrote:

> Alvaro Herrera <alvherre@kurilemu.de> 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"