Re: Startup PANIC on standby promotion due to zero-filled WAL segment - Mailing list pgsql-hackers

From Alena Vinter
Subject Re: Startup PANIC on standby promotion due to zero-filled WAL segment
Date
Msg-id CAGWv16+kR3OZfcJG8OdoU4Ja5NqqNb6=HM5yGV0zY+yJ0vMuNQ@mail.gmail.com
Whole thread Raw
In response to Re: Startup PANIC on standby promotion due to zero-filled WAL segment  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Startup PANIC on standby promotion due to zero-filled WAL segment
List pgsql-hackers
> Don't think so, based on what is in the tree:
> $ git grep "fsync = " -- *.pm
> src/test/perl/PostgreSQL/Test/Cluster.pm:   print $conf "fsync = off\n";

Oh, didn’t know it's in the `init` function — I apologize.

> The following addition to your proposed test is telling me an entirely
> different story, making the test pass as the records of TLI 1 are
> around:
> my $node_primary = PostgreSQL::Test::Cluster->new('primary');
> $node_primary->init(allows_streaming => 1);
> +#$node_primary->append_conf('postgresql.conf', 'fsync=on');
> $node_primary->start;

I've tried this way, and yes, this works fine. Now I'm really interested in how this parameter prevents the scenario with startup panic. Thank you very much!!!
But I’m still unclear why the segment isn’t copied during replication, as it is in crash recovery (I’d prefer uniform behavior across both paths). Could you help me figure out the answer to that question?
---
Alena Vinter

pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: Two issues with version checks in CREATE SUBSCRIPTION
Next
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication