On 11/21/24 13:31, Steeve Boulanger wrote:
> All I can think to do is look at the logs around the stats_reset times
> for the databases and see if there is anything relevant.
That was already done, but nothing relevant was found unfortunately.
Unless it was not recognized as relevant. Since for the time being I am
eliminating magic as the cause, something concrete is causing this and
it should be leaving a trace. In your post you had this affecting 77 out
of 157 databases in the cluster.
1) Do the 77 share some trait the other 80 don't.
2) Do the OS system logs reveal anything?
3) What was happening in the databases just prior to the time the stats
reset?
4) Do you have external tools accessing these databases?
5) Is the cluster directly open to the world?
-Steeve
On Thu, Nov 21, 2024 at 3:12 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx
<mailto:adrian.klaver@xxxxxxxxxxx>> wrote:
On 11/21/24 12:57, Steeve Boulanger wrote:
>
> > Please reply to list also.
>
> My apologies - I thought I did a "Reply all", but apparently not.
I'm a
> little bit of a noob with email distrib lists.
>
> > 1) What is log_min_error_statement set to?
>
> name | setting | pending_restart
> -------------------------+---------+-----------------
> log_min_error_statement | error | f
>
> > 2) Did you reload the server when changing?:
>
> yes - pg_reload_conf()
All I can think to do is look at the logs around the stats_reset times
for the databases and see if there is anything relevant.
>
> -Steeve
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
