From db0f6cad4884bd4c835156d3a720d9a79dbd63a9 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 9 Oct 2015 14:31:04 -0400 Subject: Remove set_latch_on_sigusr1 flag. This flag has proven to be a recipe for bugs, and it doesn't seem like it can really buy anything in terms of performance. So let's just *always* set the process latch when we receive SIGUSR1 instead of trying to do it only when needed. Per my recent proposal on pgsql-hackers. --- src/backend/tcop/postgres.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'src/backend/tcop/postgres.c') diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c index aee13aec757..d30fe35c14f 100644 --- a/src/backend/tcop/postgres.c +++ b/src/backend/tcop/postgres.c @@ -2825,9 +2825,7 @@ RecoveryConflictInterrupt(ProcSignalReason reason) /* * Set the process latch. This function essentially emulates signal * handlers like die() and StatementCancelHandler() and it seems prudent - * to behave similarly as they do. Alternatively all plain backend code - * waiting on that latch, expecting to get interrupted by query cancels et - * al., would also need to set set_latch_on_sigusr1. + * to behave similarly as they do. */ SetLatch(MyLatch); -- cgit v1.2.3