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
