Thread: Re: BF member drongo doesn't like 035_standby_logical_decoding.pl
Hi, On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote: > I realized just now that drongo has been intermittently failing like this: Thanks for the report! > PS: FTR, the hits I got on this in the past 90 days were > > sysname | branch | snapshot | stage | l > ---------+---------------+---------------------+---------------+------------------------------------------------------------------------------------------------------------ > drongo | HEAD | 2024-10-29 10:52:07 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > drongo | REL_16_STABLE | 2024-10-31 08:07:11 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_17_STABLE | 2024-11-05 11:11:28 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_16_STABLE | 2024-11-22 08:58:52 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > drongo | HEAD | 2024-11-29 22:23:47 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | HEAD | 2024-12-04 20:33:42 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_17_STABLE | 2024-12-20 17:00:28 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > drongo | HEAD | 2024-12-24 21:07:27 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > drongo | REL_16_STABLE | 2025-01-10 15:48:16 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_17_STABLE | 2025-01-10 18:05:18 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | HEAD | 2025-01-11 20:40:09 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_16_STABLE | 2025-01-12 14:06:11 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > drongo | REL_16_STABLE | 2025-01-13 07:19:22 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_16_STABLE | 2025-01-14 10:48:16 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | HEAD | 2025-01-20 20:11:00 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_16_STABLE | 2025-01-24 01:54:55 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > drongo | REL_17_STABLE | 2025-01-24 04:21:44 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r Out of curiosity, how did you generate this output? (that looks wery useful) Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote:
>> PS: FTR, the hits I got on this in the past 90 days were
>>
>> sysname | branch | snapshot | stage |
l
>>
---------+---------------+---------------------+---------------+------------------------------------------------------------------------------------------------------------
>> drongo | HEAD | 2024-10-29 10:52:07 | recoveryCheck | # Failed test 'activeslot slot invalidation is
loggedwith vacuum on pg_class'\r\r
>> drongo | REL_16_STABLE | 2024-10-31 08:07:11 | recoveryCheck | # Failed test 'activeslot slot invalidation is
loggedwith vacuum on pg_authid'\r\r
>> ...
> Out of curiosity, how did you generate this output? (that looks wery useful)
That is from a SQL query on the database that stores the last few
months' worth of buildfarm logs. I believe current policy is that
only committers will be granted access to that machine, partly
because of security concerns and partly because of resource
limitations. But in the interests of transparency, what I did was
pgbfprod=> select * from
(select sysname, s.branch, snapshot, stage,
unnest(string_to_array(log_text, E'\n')) as l
from build_status s join build_status_log l using (sysname, snapshot)
where stage != 'OK' and snapshot > localtimestamp - '3 mons'::interval) ss
where l like '%Failed test%activeslot slot invalidation%'
\g outfile
(Other than the specific string-to-search-for, this is a canned
query pattern that I use a lot. It scans all failed tests' logs
in the past 3 months.) I did some manual duplicate-removal
and hand filtering afterwards, IIRC.
regards, tom lane
Hi, On Mon, Jan 27, 2025 at 09:28:57AM -0500, Tom Lane wrote: > Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes: > > On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote: > >> PS: FTR, the hits I got on this in the past 90 days were > >> > >> sysname | branch | snapshot | stage | l > >> ---------+---------------+---------------------+---------------+------------------------------------------------------------------------------------------------------------ > >> drongo | HEAD | 2024-10-29 10:52:07 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_class'\r\r > >> drongo | REL_16_STABLE | 2024-10-31 08:07:11 | recoveryCheck | # Failed test 'activeslot slot invalidation is loggedwith vacuum on pg_authid'\r\r > >> ... > > > Out of curiosity, how did you generate this output? (that looks wery useful) > > That is from a SQL query on the database that stores the last few > months' worth of buildfarm logs. I believe current policy is that > only committers will be granted access to that machine, partly > because of security concerns and partly because of resource > limitations. Makes sense. > But in the interests of transparency, what I did was > > pgbfprod=> select * from > (select sysname, s.branch, snapshot, stage, > unnest(string_to_array(log_text, E'\n')) as l > from build_status s join build_status_log l using (sysname, snapshot) > where stage != 'OK' and snapshot > localtimestamp - '3 mons'::interval) ss > where l like '%Failed test%activeslot slot invalidation%' > \g outfile > > (Other than the specific string-to-search-for, this is a canned > query pattern that I use a lot. It scans all failed tests' logs > in the past 3 months.) I did some manual duplicate-removal > and hand filtering afterwards, IIRC. > Thanks for the explanation! Having access to this database looks like a big time saver in some situations. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com