RE: Restore of a reference database kills the auto analyze processing.

2024-06-18 Thread HORDER Philip
Classified as: {OPEN} Installing 15.7 has indeed fixed the problem. Phil Horder Database Mechanic Thales Land & Air Systems {OPEN} The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. I

Re: Restore of a reference database kills the auto analyze processing.

2024-05-23 Thread HORDER Philip
Classified as: {OPEN} I actually hadn't thought to look for Postgres bugs, the system is so reliable for us, it just doesn't go wrong! I can trigger the fault be running a reload of the lfm database, and we've been running Postgres 10 & 13 for several years now without seeing this problem. Our

Re: Restore of a reference database kills the auto analyze processing.

2024-05-22 Thread HORDER Philip
Classified as: {OPEN} > https://www.postgresql.org/docs/15/release-15-5.html#id-1.11.6.7.4 > Fix race condition in database dropping that could lead to the autovacuum > launcher getting stuck Wow, that sounds like our problem! I will investigate. Maybe try and find the orphaned stats entry to

Re: Restore of a reference database kills the auto analyze processing.

2024-05-22 Thread HORDER Philip
Classified as: {OPEN} > Just for confirmation your settings are still?: > autovacuum_max_workers = 10 > log_autovacuum_min_duration = 0 Yes. > You said previously: > "The only way I can find of getting the analyzer back is to restart Postgres." > > To be clear this means: > 1) The lfm database

Re: Restore of a reference database kills the auto analyze processing.

2024-05-21 Thread HORDER Philip
Classified as: {OPEN} 2024-05-15 03:31:31.290 GMT [4556]: [3-1] db=lfm,user=superuser,app=[unknown],client=::1 LOG: connection authorized: user=superuser database=lfm application_name=pg_restore > That would be the lfm database being restored. > What does the log show after that as pertains to a

Re: Restore of a reference database kills the auto analyze processing.

2024-05-21 Thread HORDER Philip
Classified as: {OPEN} > I am having a hard time figuring out how both of the above can be true. > Dropping and recreating the database would wipe out the statistics. We have multiple databases on the one Postgres server. The 'postgres' database contains our main application, with tables in schema

RE: Restore of a reference database kills the auto analyze processing.

2024-05-21 Thread HORDER Philip
Classified as: {OPEN} > Assuming clean shutdowns the statistics will survive restarts. They would be > wiped when you drop a database and start over, have an unclean shutdown or > you use one of the reset functions... Yes, stats are permanent, but are not being updated. We don't use any of the

Re: Restore of a reference database kills the auto analyze processing.

2024-05-16 Thread HORDER Philip
Classified as: {OPEN} Adrian, > Still your contention was that autovacuum quit running after the initial > restore and that is not the case This Postgres server has been restarted a few times since 2nd May most recently on Tuesday 14th, hence the more recent analyze status. We've had some

Re: Restore of a reference database kills the auto analyze processing.

2024-05-16 Thread HORDER Philip
Classified as: {OPEN} > Did you have chance to do below? > Using psql do > \x > select * from pg_stat_all_tables where relname = 'a.accp'; Sorry, missed that bit. From this output you can see that no stats have been collected since the last two overnight updates. postgres=# select * from pg_st

Re: Restore of a reference database kills the auto analyze processing.

2024-05-16 Thread HORDER Philip
Classified as: {OPEN} > --oids have not been supported with pg_dump since v11 You're absolutely correct, this command came from my notes, which are obviously out of date. We're running Postgres 15 pg_dump, and I've updated my notes. I'm double-checking the command options with the guy who creat

RE: Restore of a reference database kills the auto analyze processing.

2024-05-15 Thread HORDER Philip
Classified as: {OPEN} Backups of this db are created with: pg_dump --file=fsm.dmp -Fc --blobs --oids --dbname=lfm --host=localhost --port= --username=superuser Restore is run with: dropdb --port= --maintenance-db=postgres --username=superuser --if-exists lfm pg_restore -Fc --create -

RE: Restore of a reference database kills the auto analyze processing.

2024-05-07 Thread HORDER Philip
Thanks for your time Adrian > Is there enough data processing? Yes, one table is receiving upwards of 20 million rows daily. We noticed the problem when fetch performance on this table degraded after updates. > Autovacuum has thresholds for turning on, are you sure those thresholds are > just

RE: Restore of a reference database kills the auto analyze processing.

2024-05-07 Thread HORDER Philip
Sorry, pg_dump. Phil Horder Database Mechanic -Original Message- From: Adrian Klaver Sent: 02 May 2024 17:59 To: HORDER Philip ; pgsql-general@lists.postgresql.org Subject: [EXTERNAL EMAIL] Re: Restore of a reference database kills the auto analyze processing. On 5/2/24 8:52 AM

Restore of a reference database kills the auto analyze processing.

2024-05-02 Thread HORDER Philip
Running Postgres 15.3 with PostGIS 3.3 On Windows 10 (yes, I know) It's a single node db with no replication, topping out at about 200GB. We have a schema (A) in the default 'postgres' maintenance database, which our software services connect to, with one set of users (SU) We have another datab