View Issue Details

IDProjectCategoryView StatusLast Update
0000272Pgpool-IIBugpublic2017-02-23 16:11
Reportergianpaolo.dininoAssigned Tot-ishii 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000272: pgpool not releasing shared memory segments
DescriptionHi,

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 ReproduceIf 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.
Tagsstreaming replication

Activities

t-ishii

2016-12-20 12:42

developer   ~0001238

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.
Patch attached.

t-ishii

2016-12-20 12:42

developer  

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)

mmusenbr

2017-02-06 16:57

reporter   ~0001331

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?

t-ishii

2017-02-23 16:11

developer   ~0001355

Thanks for the report. I have committed and pushed the patch to all supported branches.

Issue History

Date Modified Username Field Change
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