On Fri, 23 Nov 2018 15:54:38 -0600 Dimitri Maziuk via Bacula-users wrote: > If it still hasn't gone down, check your > postgresql.conf for > > #wal_level = replica # minimal, > replica, or logical # (change requires restart) > > If the above is what you have, you could change it to > wal_level = minimal > and restart.
Trying this results in (journalclt excerpt): Nov 24 01:11:05 pc postgresql-script[6374]: 2018-11-24 01:11:05.565 EET [6383]FATAL: WAL streaming (max_wal_senders > 0) requires wal_level "replica" or "logical" Nov 24 01:11:05 pc postgresql-script[6374]: pg_ctl: could not start server Nov 24 01:11:05 pc postgresql-script[6374]: Examine the log output. Nov 24 01:11:05 pc systemd[1]: postgresql.service: Control process exited, code=exited status=1 Nov 24 01:11:05 pc systemd[1]: Failed to start PostgreSQL database server. So I commented it back and restarted. > FWIW I just checked another of out postgresql-10 > hosts, this one does a lot of truncates and loaded > on a 10^6+ rows DB, it has #max_wal_size = 1GB > and ~999.5MB in pg_wal when idle. Thanks for the additional info. Right now in pg_wal I have 769MB with 47x16MB files from 19.Nov and 1x16MB from this exact moment. FWIW on this system there isn't any pgsql activity as the only database is that of bacula (and it is still empty as I was waiting for your reply). I read that: https://www.postgresql.org/docs/10/runtime-config-wal.html#GUC-MAX-WAL-SIZE After re-running a few times the scripts for export/import from/to mysql/psql the situation is: # du -hs ~/data/pg_wal/ 769M /var/lib/pgsql/data/pg_wal/ with 11x16MB from this moment and the others from 19.Nov. So obviously some WAL rotation does occur oldest files are replaced by new ones which keeps the overall WAL data the same. I guess this answers my main concern about WAL data (not) filling up the partition. Thank you. -- George _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users