Re: Improve error reporting in 027_stream_regress test
От | Alexander Lakhin |
---|---|
Тема | Re: Improve error reporting in 027_stream_regress test |
Дата | |
Msg-id | 29b637df-f818-4b52-986a-f11ba28300e9@gmail.com обсуждение исходный текст |
Ответ на | Re: Improve error reporting in 027_stream_regress test (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Improve error reporting in 027_stream_regress test
|
Список | pgsql-hackers |
Hello Nazir and Michael! 01.07.2025 10:57, Nazir Bilal Yavuz wrote: > I agree with you. So, the current logic is: > > If primary is not alive: Do not report anything. > If only primary is alive: Report the entire diff file. > If both primary and standby are alive: Report entire diff file and add > head+tail of diff to the failure message. > > Done like above in v2. The new check has failed on mamba [1], apparently because this animal is too slow for pg_isready: regress_log_027_stream_regress: ... # Running: pg_isready --host /home/buildfarm/bf-data/tmp/ep8AOH4m7l --port 24781 /home/buildfarm/bf-data/tmp/ep8AOH4m7l:24781 - no response [08:01:50.899](1505.313s) ok 2 - regression tests pass [08:01:50.902](0.003s) ok 3 - primary alive after regression test run [08:01:50.905](0.003s) not ok 4 - standby alive after regression test run [08:01:50.908](0.003s) [08:01:50.908](0.000s) # Failed test 'standby alive after regression test run' # at t/027_stream_regress.pl line 104. [08:01:50.909](0.001s) # got: '0' # expected: '1' 027_stream_regress_standby_1.log: 2025-07-28 07:37:27.237 EDT [22920:1] LOG: starting PostgreSQL 19devel on powerpc-unknown-netbsd10.1, compiled by cc (nb3 20231008) 10.5.0, 32-bit 2025-07-28 07:37:27.239 EDT [22920:2] LOG: listening on Unix socket "/home/buildfarm/bf-data/tmp/ep8AOH4m7l/.s.PGSQL.24781" 2025-07-28 07:37:27.281 EDT [25395:1] LOG: database system was interrupted; last known up at 2025-07-28 07:36:48 EDT 2025-07-28 07:37:27.282 EDT [25395:2] LOG: starting backup recovery with redo LSN 0/02000028, checkpoint LSN 0/02000080, on timeline ID 1 2025-07-28 07:37:27.283 EDT [25395:3] LOG: entering standby mode 2025-07-28 07:37:27.287 EDT [25395:4] LOG: redo starts at 0/02000028 ... 2025-07-28 08:01:47.884 EDT [6985:1] [unknown] LOG: connection received: host=[local] 2025-07-28 08:01:48.261 EDT [6985:2] [unknown] LOG: connection authenticated: user="buildfarm" method=trust (/home/buildfarm/bf-data/HEAD/pgsql.build/src/test/recovery/tmp_check/t_027_stream_regress_standby_1_data/pgdata/pg_hba.conf:117) 2025-07-28 08:01:48.261 EDT [6985:3] [unknown] LOG: connection authorized: user=buildfarm database=postgres application_name=027_stream_regress.pl 2025-07-28 08:01:51.552 EDT [6985:4] 027_stream_regress.pl LOG: could not send data to client: Broken pipe ### 3 seconds is the pg_isready's default timeout 2025-07-28 08:01:51.552 EDT [6985:5] 027_stream_regress.pl FATAL: connection to client lost 2025-07-28 08:01:51.552 EDT [6985:6] 027_stream_regress.pl LOG: disconnection: session time: 0:00:03.670 user=buildfarm database=postgres host=[local] ... What do you think of increasing the timeout (e.g. , to 10 seconds)? [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2025-07-28%2007%3A46%3A26 Best regards, Alexander
В списке pgsql-hackers по дате отправления: