Re: Proposal: Recent mutated table tracking in memory

Hi Nadav,

Sorry for late response. I have been working on this issue.

> > Added some handling for possible causes - works now.
>
> Unfortunately this doesn't work here. Still 042 test fails if it is
> executed *after* 041. i.e.
>
> ./regress.sh 04[12] <-- 042 fails
> ./regress.sh 042 <-- Ok

I ran following script to see if some sockets are left after the 041 test.

./regress.sh '041';netstat -ap|grep 11000;./regress.sh 042
:
testing 041.external_replication_delay...ok.
out of 1 ok:1 failed:0 timeout:0
(一部のプロセスが識別されますが, 所有していないプロセスの情報は
表示されません。それら全てを見るにはルートになる必要があります.)
tcp 0 0 0.0.0.0:11000 0.0.0.0:* LISTEN 1401942/bash
tcp 0 0 localhost:36366 localhost:11000 TIME_WAIT -
tcp 0 0 localhost:36380 localhost:11000 TIME_WAIT -
tcp 0 0 localhost:36384 localhost:11000 TIME_WAIT -
tcp 0 0 localhost:36390 localhost:11000 TIME_WAIT -
tcp 0 0 localhost:43580 localhost:11000 TIME_WAIT -
tcp 0 0 localhost:43596 localhost:11000 TIME_WAIT -
tcp6 0 0 [::]:11000 [::]:* LISTEN 1401942/bash
unix 2 [ ACC ] STREAM LISTENING 10164557 1401942/bash /tmp/.s.PGSQL.11000
creating pgpool-II temporary installation ...
moving pgpool_setup to temporary installation path ...
moving watchdog_setup to temporary installation path ...
using pgpool-II at /home/t-ishii/work/Pgpool-II/current/pgpool2/src/test/regression/temp/installed
*************************
REGRESSION MODE : install
Pgpool-II version : pgpool-II version 4.8devel (mitsukakeboshi)
Pgpool-II install path : /home/t-ishii/work/Pgpool-II/current/pgpool2/src/test/regression/temp/installed
PostgreSQL bin : /usr/local/pgsql/bin
PostgreSQL Major version : 18
pgbench : /usr/local/pgsql/bin/pgbench
PostgreSQL jdbc : /usr/local/pgsql/share/postgresql-9.2-1003.jdbc4.jar
*************************
testing 042.track_table_mutation...failed.
out of 1 ok:0 failed:1 timeout:0

It seems the cause of the issue is the bash process:

unix 2 [ ACC ] STREAM LISTENING 10164557 1401942/bash /tmp/.s.PGSQL.11000

It keeps on listening to the socket even after the test and it
prevents pgpool in 042 test from binding the socket, which causes the
test failure. Possible solutions are:

1) fix the external replication delay checking to close the listening
socket before starting bash.

2) close the listening socket when the streaming replication check
worker process forks.

While invensting the issue, I found similar problem is in other
places. For example, pcp process inherits pgpool listening sockets
which are not necessary for pcp. I posted a proposal to fix the issue:

https://www.postgresql.org/message-id/20260302.100028.1346768433787074248.ishii%40postgresql.org

This includes the fix #2. I plan to commit the patch today. After our
buildfarm reports no new problem (it will take 2- 3 days), I am going
to test your patch again.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp