Re: Bug: WAIT FOR LSN crashes with assertion failure inside PL/pgSQL DO blocks and procedures

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug: WAIT FOR LSN crashes with assertion failure inside PL/pgSQL DO blocks and procedures
Date: 2026-04-09 06:00:06
Message-ID: CAPpHfdsZ6YrzX-5uenwvw1VXuG7mpBXSOT6JFTg6aCCC0SaNEg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Satya!

On Thu, Apr 9, 2026 at 5:03 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
> An assertion failure (server crash in assert-enabled builds) occurs when WAIT FOR LSN ... INTO is used inside PL/pgSQL DO blocks or within void procedures.
>
> Repro:
>
> -- Run this on a standby
>
> CREATE PROCEDURE test_wait()
> LANGUAGE plpgsql AS $$
> DECLARE
> result text;
> BEGIN
> WAIT FOR LSN '0/1234' INTO result;
> RAISE NOTICE '%', result;
> END;
> $$;
> CALL test_wait();
>
>
> The WAIT FOR itself succeeds, but the very next PL/pgSQL statement that requires a snapshot crashes the backend with:
>
> TRAP: failed Assert("portal->portalSnapshot == NULL"),
> File: "pquery.c", Line: 1776
>
> Attached patches for both the test case and a potential fix. Please review.

Thank you for reporting. But I doubt the fix is correct. Even that
this particular might work OK, I don't think it's safe to release
snapshots belonging to functions/procedures: it might affect them. I
tend to think we must forbid wrapping WAIT FOR LSN with
functions/procedures. I'll explore more on this today.

------
Regards,
Alexander Korotkov
Supabase

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message wang.xiao.peng 2026-04-09 06:12:39 Re:Re: pg_test_timing: fix unit typo and widen diff type
Previous Message Xing Guo 2026-04-09 05:13:59 [PATCH] Use mul_size for allocation products potentially to overflow