aboutsummaryrefslogtreecommitdiff
path: root/src/common/file_utils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-05-14 10:22:28 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2019-05-14 10:22:28 -0400
commitfb489e4b3195fc33cccc0fd308e5a0ab502cf199 (patch)
tree5411954508bbe7cd004e7a88ce933b17f88cc9d8 /src/common/file_utils.c
parent037165ca95d854e04c0c28cfa85f1515bd852892 (diff)
downloadpostgresql-fb489e4b3195fc33cccc0fd308e5a0ab502cf199.tar.gz
postgresql-fb489e4b3195fc33cccc0fd308e5a0ab502cf199.zip
In bootstrap mode, use default signal handling for SIGINT etc.
Previously, the code pointed the standard process-termination signals to postgres.c's die(). That would typically result in an attempt to execute a transaction abort, which is not possible in bootstrap mode, leading to PANIC. This choice seems to be a leftover from an old code structure in which the same signal-assignment code was used for many sorts of auxiliary processes, including interactive standalone backends. It's not very sensible for bootstrap mode, which has no interest in either interactivity or continuing after an error. We can get better behavior with less effort by just letting normal process termination happen, after which the parent initdb process will clean up. This is basically cosmetic in any case, since initdb will react the same way whether bootstrap dies on a signal or abort(). Given the lack of previous complaints, I don't feel a need to back-patch, even though the behavior is old. Discussion: https://postgr.es/m/3850b11a.5121.16aaf827e4a.Coremail.thunder1@126.com
Diffstat (limited to 'src/common/file_utils.c')
0 files changed, 0 insertions, 0 deletions