View Issue Details

IDProjectCategoryView StatusLast Update
0000004Pgpool-IIBugpublic2012-02-22 15:21
ReportertuomasAssigned Tot-ishii 
Status closedResolutionfixed 
PlatformLinuxOSUbuntuOS Version11.04
Product Version 
Target VersionFixed in Version 
Summary0000004: pgpool doesn't exit on term signal even if all connections are idle
DescriptionWhen you send term signal to pgpool's main process, all childs that are in state "wait for connection request" state die nicely, but those that have an idle connection wont. They just hang there and need to be kill -9'd:

pgpool 31514 pgpool -n
pgpool 31610 pgpool: wait for connection request
pgpool 31611 pgpool: wait for connection request
pgpool 31612 pgpool: wait for connection request
pgpool 31613 pgpool: userX dbY hostZ(port) idle

$ kill 31514

pgpool 31514 pgpool -n
pgpool 31613 pgpool: userX dbY hostZ(port) idle

When I run it in debug mode i also get this in the log:
"child receives smart shutdown request but it's not in idle state"

The client certainly was idle.

Steps To ReproduceRun pgpool, open some connections, keep them idle, send term signal to pgpool main process.
TagsNo tags attached.


2012-02-13 13:23

reporter   ~0000005

This is actually an intended feature in order to mirror PostgreSQL's signal handling capability. Send the backend a SIGINT to perform a fast shutdown.


2012-02-14 19:37

reporter   ~0000007

Right. Thought smart mode worked so that it would detect if the connection (client) was idle (not executing a query) and then close it, but i guess it just checks if the child is idle (doesn't have a connection).

SIGINT indeed seems to do the job.

So this one can be closed. Not a bug.


2012-02-22 15:21

developer   ~0000009

This was not actually an issue. See notes.

Issue History

Date Modified Username Field Change
2012-02-11 00:25 tuomas New Issue
2012-02-13 13:23 Note Added: 0000005
2012-02-14 19:37 tuomas Note Added: 0000007
2012-02-22 15:21 t-ishii Note Added: 0000009
2012-02-22 15:21 t-ishii Status new => closed
2012-02-22 15:21 t-ishii Assigned To => t-ishii
2012-02-22 15:21 t-ishii Resolution open => fixed