On Mon, Jul 26, 2021 at 03:53:20PM -0400, Robert Haas wrote: > Yeah, and there again, it's a lot easier to test if we don't have as > many cases. Now no single change is going to fix that, but the number > of flag variables in xlog.c is simply bonkers. This particular stretch > of code uses 3 of them to even decide whether to attempt the test in > question, and all of those are set in complex ways depending on the > values of still more flag variables. The comments where > bgwriterLaunched is set claim that we only do this during archive > recovery, not crash recovery, but the code depends on the value of > ArchiveRecoveryRequested, not InArchiveRecovery. So I wonder if we > can't get the bgwriter to run even during crash recovery in the > scenario described by:
I'm not following along closely and maybe you're already aware of this one? https://commitfest.postgresql.org/33/2706/ Background writer and checkpointer in crash recovery @Thomas: https://www.postgresql.org/message-id/CA%2BTgmoYmw%3D%3DTOJ6EzYb_vcjyS09NkzrVKSyBKUUyo1zBEaJASA%40mail.gmail.com > * It's possible that archive recovery was requested, but we don't > * know how far we need to replay the WAL before we reach consistency. > * This can happen for example if a base backup is taken from a > * running server using an atomic filesystem snapshot, without calling > * pg_start/stop_backup. Or if you just kill a running primary server > * and put it into archive recovery by creating a recovery signal > * file. > > If we ran the bgwriter all the time during crash recovery, we'd know > for sure whether that causes any problems. If we only do it like this > in certain corner cases, it's much more likely that we have bugs. > Grumble, grumble. -- Justin