agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() 3+ messages / 1 participants [nested] [flat]
* pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() @ 2026-08-04 08:09 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Fujii Masao @ 2026-08-04 08:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix error handling in getCopyDataMessage() and pqFunctionCall3() Commit f6f0542266f0 changed getNotify(), getParameterStatus(), and related libpq message-processing paths to abandon the connection on out-of-memory errors. However, getCopyDataMessage() and pqFunctionCall3() did not handle this new fatal-error state. Both can process asynchronous NotificationResponse and ParameterStatus messages while waiting for other responses. If one of those messages triggered a fatal error, these loops continued processing instead of reporting it immediately. Fix this by checking for a saved fatal error after processing an asynchronous message. If the connection has been abandoned, return the appropriate error immediately instead of continuing to parse input. Backpatch to v18, where commit f6f0542266f0 introduced this issue. Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAO6_XqpGfm+XHE1OzS=_+jroeDOxhhGa11P3cbm9q2gT05yorA@mail.gmail.com Backpatch-through: 18 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/676bf48e1e5241f1da4088515ae4ce9fd435e417 Modified Files -------------- src/interfaces/libpq/fe-protocol3.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() @ 2026-08-04 08:09 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Fujii Masao @ 2026-08-04 08:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix error handling in getCopyDataMessage() and pqFunctionCall3() Commit f6f0542266f0 changed getNotify(), getParameterStatus(), and related libpq message-processing paths to abandon the connection on out-of-memory errors. However, getCopyDataMessage() and pqFunctionCall3() did not handle this new fatal-error state. Both can process asynchronous NotificationResponse and ParameterStatus messages while waiting for other responses. If one of those messages triggered a fatal error, these loops continued processing instead of reporting it immediately. Fix this by checking for a saved fatal error after processing an asynchronous message. If the connection has been abandoned, return the appropriate error immediately instead of continuing to parse input. Backpatch to v18, where commit f6f0542266f0 introduced this issue. Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAO6_XqpGfm+XHE1OzS=_+jroeDOxhhGa11P3cbm9q2gT05yorA@mail.gmail.com Backpatch-through: 18 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8380013cd288ca35d225f862c809ec64b563d4fd Modified Files -------------- src/interfaces/libpq/fe-protocol3.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() @ 2026-08-04 08:10 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Fujii Masao @ 2026-08-04 08:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix error handling in getCopyDataMessage() and pqFunctionCall3() Commit f6f0542266f0 changed getNotify(), getParameterStatus(), and related libpq message-processing paths to abandon the connection on out-of-memory errors. However, getCopyDataMessage() and pqFunctionCall3() did not handle this new fatal-error state. Both can process asynchronous NotificationResponse and ParameterStatus messages while waiting for other responses. If one of those messages triggered a fatal error, these loops continued processing instead of reporting it immediately. Fix this by checking for a saved fatal error after processing an asynchronous message. If the connection has been abandoned, return the appropriate error immediately instead of continuing to parse input. Backpatch to v18, where commit f6f0542266f0 introduced this issue. Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> Reviewed-by: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAO6_XqpGfm+XHE1OzS=_+jroeDOxhhGa11P3cbm9q2gT05yorA@mail.gmail.com Backpatch-through: 18 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6b46a5d1b6164f2fdb15229dea9f3ed94ef20760 Modified Files -------------- src/interfaces/libpq/fe-protocol3.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-08-04 08:10 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-04 08:09 pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() Fujii Masao <fujii@postgresql.org> 2026-08-04 08:09 pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() Fujii Masao <fujii@postgresql.org> 2026-08-04 08:10 pgsql: Fix error handling in getCopyDataMessage() and pqFunctionCall3() Fujii Masao <fujii@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox