| 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
| 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 |