On Mon, Jun 08, 2020 at 05:40:20PM -0700, Peter Geoghegan wrote: ! ! I strongly suspect that you were hit by the bug fixed in commit ! 4e87c483. You should upgrade to Postgres 12.3 ASAP, to get that fix: ! ! "Avoid premature recycling of WAL segments during crash recovery ! (Jehan-Guillaume de Rorthais) ! ! WAL segments that become ready to be archived during crash recovery ! were potentially recycled without being archived." Ahh, thank You so much; this is good news: if it is an already known bug, I can close all efforts, remove the debug-switches again, stuff the sources back into their box and relax. ;) I did a check if I would find something about lost archiving logs, but didn't - and then it is always possible that it's just a mistake of mine - as I know I do make mistakes. And now for the nitpicking part :) On Mon, Jun 08, 2020 at 05:35:40PM -0700, Adrian Klaver wrote: ! > I am doing RedoLog Archiving according to Docs Chapter 25.1. ! ! There is no ReDo logging, there is WAL logging. Yes I know - and i don't care. Technically they're no longer WAL when they're going to be archived. Their purpose then becomes to redo the transactions, and even the messages say so: ! > LOG: 00000: redo done at 17/FF01C098 ! What docs, because section 25.1 in the Postgres docs is : ! ! https://www.postgresql.org/docs/12/backup-dump.html ! ! 25.1. SQL Dump Ups, mistake of mine. Should be 25.3.1. ! https://www.postgresql.org/docs/12/server-shutdown.html ! " ! Important ! ! It is best not to use SIGKILL to shut down the server. Doing so will prevent ! the server from releasing shared memory and semaphores. Furthermore, SIGKILL ! kills the postgres process without letting it relay the signal to its ! subprocesses, so it might be necessary to kill the individual subprocesses ! by hand as well. And which of these would be of any concern if the machine is rebooted anyway? I had to install new hardware, and currently I'm trying to identify a memory exhaustion issue. This makes it necessary to reboot the full system quite often, and I neither want to wait for orderly termination of dozens of subsytems, nor do I want to need fsck at restart. This would make SIGKILL/reboot the method of choice. ! What is RedoLog.bck? The script which one has to write according to the docs' section which would be correctly numbered 25.3.1. cheerio, PMc
