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
