Hi, On Mon, Jan 27, 2025 at 09:28:57AM -0500, Tom Lane wrote: > Bertrand Drouvot <bertranddrouvot...@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 logged with vacuum on pg_class'\r\r > >> drongo | REL_16_STABLE | 2024-10-31 08:07:11 | recoveryCheck | # Failed > >> test 'activeslot slot invalidation is logged with 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
