From 03a571a4cf26e06ff504e5b38a9432a003008c19 Mon Sep 17 00:00:00 2001 From: Magnus Hagander Date: Mon, 19 Apr 2010 14:10:45 +0000 Subject: Add wrapper function libpqrcv_PQexec() in the walreceiver that uses async libpq to send queries, making the waiting for responses interruptible on platforms where PQexec() can't normally be interrupted by signals, such as win32. Fujii Masao and Magnus Hagander --- src/backend/replication/walreceiver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'src/backend/replication/walreceiver.c') diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index 090111bb11..f2694db873 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -29,7 +29,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/replication/walreceiver.c,v 1.8 2010/04/13 08:16:09 mha Exp $ + * $PostgreSQL: pgsql/src/backend/replication/walreceiver.c,v 1.9 2010/04/19 14:10:45 mha Exp $ * *------------------------------------------------------------------------- */ @@ -86,8 +86,8 @@ static void DisableWalRcvImmediateExit(void); * We can't just exit(1) within SIGTERM signal handler, because the signal * might arrive in the middle of some critical operation, like while we're * holding a spinlock. We also can't just set a flag in signal handler and - * check it in the main loop, because we perform some blocking libpq - * operations like PQexec(), which can take a long time to finish. + * check it in the main loop, because we perform some blocking operations + * like libpqrcv_PQexec(), which can take a long time to finish. * * We use a combined approach: When WalRcvImmediateInterruptOK is true, it's * safe for the signal handler to elog(FATAL) immediately. Otherwise it just -- cgit v1.2.1