View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000272||pgpool-II||Bug||public||2016-12-17 00:58||2017-02-23 16:11|
|Target Version||Fixed in Version|
|Summary||0000272: pgpool not releasing shared memory segments|
we are using Freebsd 10.3, and after restarting pgpool different times we were not able anymore to create shared mem segments;
pid 51116: FATAL: could not create shared memory for request size: 6144
pid 51116: DETAIL: shared memory creation failed with error "No error: 0"
Investing the code we came up with a problem in the IpcMemoryDelete in utils/pool_shmem.c @line 107
The function checks the number of processes attached to the memory segment and it returns 2.. but this 2 processes are pgpool itself (and maybe watchdog?). So it's returning without releasing the segment.
This cause the creation of a lot of segments if you start and stop pgpool continuously (and in a testing fase it could be normal). Lot of segments bring to reach the shmem OS configuration limit and than suddenly stops (pgpool) working.
We solved this with a cronjab that periodically delete shared memory segments with no attached processes. But we don't know if this is safe.
|Steps To Reproduce||If you want to reproduce the error just run pgpool, check segments with ipcs -m (or -p i bsd) and see the segments growing, then stop pgpool and you should see created segments still there.|
Thank you for the report.
The source file was imported from PostgreSQL long time ago. I have dig into PostgreSQL 9.5 source code, and found that PostgreSQL does not check the segment attaching number anymore. So it seems it's safe unconditionally to call shmctl.
bug272.diff (451 bytes)
diff --git a/src/utils/pool_shmem.c b/src/utils/pool_shmem.c index 1b8399b..71c5a98 100644 --- a/src/utils/pool_shmem.c +++ b/src/utils/pool_shmem.c @@ -104,8 +104,10 @@ IpcMemoryDelete(int status, Datum shmId) if (shmctl(shmId, IPC_STAT, &shmStat) < 0 && (errno == EINVAL || errno == EACCES)) return; +#ifdef NOT_USED else if (shmStat.shm_nattch != 0) return; +#endif if (shmctl(shmId, IPC_RMID, NULL) < 0) ereport(LOG,
bug272.diff (451 bytes)
We (not the original reporter) had the same issue, and the patch fixed the problem.
The segments will exist anyway until the last process detaches, even after the shmctl call.
The problem did not exists in version 3.4, was there a expected change that the pgpool processes are still running while the shared memory is deinitialized?
||Thanks for the report. I have committed and pushed the patch to all supported branches.|
|2016-12-17 00:58||gianpaolo.dinino||New Issue|
|2016-12-17 00:58||gianpaolo.dinino||Tag Attached: streaming replication|
|2016-12-20 09:33||t-ishii||Assigned To||=> t-ishii|
|2016-12-20 09:33||t-ishii||Status||new => assigned|
|2016-12-20 12:42||t-ishii||Note Added: 0001238|
|2016-12-20 12:42||t-ishii||File Added: bug272.diff|
|2016-12-20 14:07||t-ishii||Status||assigned => feedback|
|2017-02-06 16:57||mmusenbr||Note Added: 0001331|
|2017-02-23 16:11||t-ishii||Note Added: 0001355|
|2017-02-23 16:11||t-ishii||Status||feedback => resolved|