Re: Timeout failure in 019_replslot_limit.pl

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.ntt@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/