Re: Async-unsafe functions in signal handlers - Mailing list pgsql-hackers

From Denis Smirnov
Subject Re: Async-unsafe functions in signal handlers
Date
Msg-id EBEA13C1-5900-49CB-8DED-5AFE23167C27@arenadata.io
Whole thread Raw
In response to Re: Async-unsafe functions in signal handlers  (Denis Smirnov <sd@arenadata.io>)
List pgsql-hackers
Honestly, I don’t know what to do with bgworker_die(). At the moment it produces ereport(FATAL) with async-unsafe proc_exit_prepare() and exit() underhood. I can see three solutions:

1. Leave the code as is. Then SIGTERM can produce deadlocks in bgworker's signal handler. The locked process can terminated with an immediate shutdown of the cluster. May be it is ok as we don’t expect to send SIGTERM to bgworker too often.

2. Use async-safe _exit() in a signal handler instead of proc_exit_prepare() and exit(). In this case we’ll have to go through cluster recovery as the bgworker doesn't properly clean its shared memory. This solution is even worth than immediate shutdown as we recover for every SIGTERM have been sent to bgworker.

3. Set a signal flag inside the handler (something like miscadmin.h XXX_INTERRUPTS() macros). So it becomes an extension developer's responsibility to properly handle this flag in the bgworker’s code. This approach breaks backward compatibility.

May be I've missed a good solution, do you see any?

Best regards,
Denis Smirnov | Developer
sd@arenadata.io 
Arenadata | Godovikova 9-17, Moscow 129085 Russia

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Avoid using ambiguous word "positive" in error message.
Next
From: "REIX, Tony"
Date:
Subject: RE: AIX: Symbols are missing in libpq.a