From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Dubious server log messages after pg_upgrade |
Date: | 2025-03-13 00:41:29 |
Message-ID: | 2563883.1741826489@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I happened to notice these entries in a log file on a
buildfarm member [1]:
2025-03-12 15:39:53.265 UTC [7296] WARNING: found incorrect redo LSN 0/159FB60 (expected 0/40000028)
2025-03-12 15:39:53.265 UTC [7296] LOG: corrupted statistics file "pg_stat/pgstat.stat"
(this is near the end of the pg_upgrade_server.log log file).
I don't think these are related to that run's subsequent test failure,
which looks to be good old Windows randomness. I then looked into the
logs of a local BF instance that also runs xversion-upgrade tests, and
darned if I didn't find
2025-03-12 14:59:15.792 EDT [2216647] LOG: database system was shut down at 2025-03-12 14:59:13 EDT
2025-03-12 14:59:15.794 EDT [2216647] WARNING: found incorrect redo LSN 0/46F73F18 (expected 0/47000028)
2025-03-12 14:59:15.794 EDT [2216647] LOG: corrupted statistics file "pg_stat/pgstat.stat"
2025-03-12 14:59:15.795 EDT [2216644] LOG: database system is ready to accept connections
despite that run having completed with no report of trouble.
So this may have been going on for quite some time without our
noticing. The "corrupted statistics file" whine is most likely
caused by pg_upgrade copying the old system's pgstat.stat file
into the new installation --- is that a good idea? I have
no idea what's causing the redo LSN complaint, but it seems
like that might deserve closer investigation.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-03-12%2012%3A48%3A39
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-03-13 00:42:17 | Re: PGSERVICEFILE as part of a normal connection string |
Previous Message | Euler Taveira | 2025-03-13 00:28:13 | Re: Separate GUC for replication origins |