On 2021-Sep-20, Michael Paquier wrote: > > Can you please first test if the idea of sending the signal twice is > > enough? > > This idea does not work. I got one failure after 5 tries.
OK, thanks for taking the time to test it. > > If that doesn't work, let's try Horiguchi-san's idea of using some > > `ps` flags to find the process. > > Tried this one as well, to see the same failure. Hmm, do you mean that you used Horiguchi-san's patch in [1] and the failure still occurred? [1] https://postgr.es/m/20210907.120106.1483239898065111540.horikyota....@gmail.com > I was just looking at the state of the test while it was querying > pg_replication_slots and that was the expected state after the WAL > sender received SIGCONT: > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > toto 12663 0.0 0.0 5014468 3384 ?? Ss 8:30PM 0:00.00 postgres: > primary3: walsender toto [local] streaming 0/720000 > toto 12662 0.0 0.0 4753092 3936 ?? Ts 8:30PM 0:00.01 postgres: > standby_3: walreceiver streaming 0/7000D8 > > The test gets the right PIDs, as the logs showed: > ok 17 - have walsender pid 12663 > ok 18 - have walreceiver pid 12662 As I understood, Horiguchi-san's point isn't that the PIDs might be wrong -- the point is to make sure that the process is in state T before moving on to the next step in the test. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
