pgsql: Improve detection of child-process SIGPIPE failures.
От | Tom Lane |
---|---|
Тема | pgsql: Improve detection of child-process SIGPIPE failures. |
Дата | |
Msg-id | E1gYcSM-0008Ot-Mf@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Improve detection of child-process SIGPIPE failures. Commit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child process, but it only worked correctly if the SIGPIPE occurred in the immediate child process. Depending on the shell in use and the complexity of the shell command string, we might instead get back an exit code of 128 + SIGPIPE, representing a shell error exit reporting SIGPIPE in the child process. We could just hack up ClosePipeToProgram() to add the extra case, but it seems like this is a fairly general issue deserving a more general and better-documented solution. I chose to add a couple of functions in src/common/wait_error.c, which is a natural place to know about wait-result encodings, that will test for either a specific child-process signal type or any child-process signal failure. Then, adjust other places that were doing ad-hoc tests of this type to use the common functions. In RestoreArchivedFile, this fixes a race condition affecting whether the process will report an error or just silently proc_exit(1): before, that depended on whether the intermediate shell got SIGTERM'd itself or reported a child process failing on SIGTERM. Like the previous patch, back-patch to v10; we could go further but there seems no real need to. Per report from Erik Rijkers. Discussion: https://postgr.es/m/f3683f87ab1701bea5d86a7742b22432@xs4all.nl Branch ------ REL_11_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b1894a6076f36a20338e0c3b0eb73a250ea2e47e Modified Files -------------- src/backend/access/transam/xlogarchive.c | 20 ++++----------- src/backend/commands/copy.c | 3 +-- src/backend/postmaster/pgarch.c | 10 +++----- src/common/wait_error.c | 43 ++++++++++++++++++++++++++++++++ src/include/port.h | 2 ++ 5 files changed, 55 insertions(+), 23 deletions(-)
В списке pgsql-committers по дате отправления: