Re: Bug in asynchronous Append

From: Gleb Kashkin <g(dot)kashkin(at)postgrespro(dot)ru>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in asynchronous Append
Date: 2026-08-04 12:19:11
Message-ID: d3e5fbfbe3f8f0feb38af3c2b973bd4a@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Etsuro Fujita писал(а) 2026-08-04 14:26:
> Hi,
>
> On Tue, Aug 4, 2026 at 5:35 PM Alexander Pyhalov
> <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
>> Etsuro Fujita писал(а) 2026-08-03 16:57:
>> > Attached is an updated version of the
>> > patch.
>
>> Hi. Looks good to me.
>
> Cool! I'll push the patch and backpatch it to all supported versions.
>
> Thanks for reviewing!
>
> Best regards,
> Etsuro Fujita

Hi. It seems there is the last small issue with the patch.

The following scenario is possible:

1) During rescan, one child of the Append has already produced a tuple
and set as_needrequest
2) Another child still has callback_pending, but its postgres_fdw
connection is occupied by an async request belonging to a different
Append
3) While draining the second child, postgresForeignAsyncConfigureWait()
sees the different requestor and the stale nonempty as_needrequest, so
it returns without registering an event
4) The reset loop then repeats without making progress

See reproducer and fix in the patch. It should be applied to v2.

--
Best regards,
Gleb Kashkin,
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gleb Kashkin 2026-08-04 12:20:35 Re: Bug in asynchronous Append
Previous Message David Rowley 2026-08-04 12:09:09 Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support