pgsql: Avoid lockup of a parallel worker when reporting a long error me

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Avoid lockup of a parallel worker when reporting a long error me
Date: 2020-09-03 20:52:32
Message-ID: E1kDwDg-0002CA-Fc@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Avoid lockup of a parallel worker when reporting a long error message.

Because sigsetjmp() will restore the initial state with signals blocked,
the code path in bgworker.c for reporting an error and exiting would
execute that way. Usually this is fairly harmless; but if a parallel
worker had an error message exceeding the shared-memory communication
buffer size (16K) it would lock up, because it would wait for a
resume-sending signal from its parallel leader which it would never
detect.

To fix, just unblock signals at the appropriate point.

This can be shown to fail back to 9.6. The lack of parallel query
infrastructure makes it difficult to provide a simple test case for
9.5; but I'm pretty sure the issue exists in some form there as well,
so apply the code change there too.

Vignesh C, reviewed by Bharath Rupireddy, Robert Haas, and myself

Discussion: https://postgr.es/m/CALDaNm1d1hHPZUg3xU4XjtWBOLCrA+-2cJcLpw-cePZ=GgDVfA@mail.gmail.com

Branch
------
REL_10_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/2a938c7935cf838b99b2017c5f86f9435ad9ad7e

Modified Files
--------------
src/backend/postmaster/bgworker.c | 11 +++++++++--
src/test/regress/expected/select_parallel.out | 5 +++--
src/test/regress/sql/select_parallel.sql | 3 ++-
3 files changed, 14 insertions(+), 5 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-09-04 00:09:40 pgsql: Remove arbitrary restrictions on password length.
Previous Message Tom Lane 2020-09-03 16:16:54 pgsql: Allow records to span multiple lines in pg_hba.conf and pg_ident