Re: standby recovery fails (tablespace related) (tentative patch and discussion) - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id 20220729.142008.340873830395327221.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)
List pgsql-hackers
At Fri, 29 Jul 2022 11:27:01 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in 
> Maybe it just needs a replication slot?  I see:
> 
> ERROR:  requested WAL segment 000000010000000000000003 has already been removed

Agreed, I see the same.  The same failure can be surely reproducible
by inserting wal-switch+checkpoint after taking backup [1].  And it is
fixed by the attached.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


[1]:
--- a/src/test/recovery/t/033_replay_tsp_drops.pl
+++ b/src/test/recovery/t/033_replay_tsp_drops.pl
@@ -30,6 +30,13 @@ sub test_tablespace
     my $backup_name = 'my_backup';
     $node_primary->backup($backup_name);
 
+    $node_primary->psql(
+        'postgres',
+        qq[
+        CREATE TABLE t(); DROP TABLE t; SELECT pg_switch_wal();
+        CHECKPOINT;
+        ]);
+
     my $node_standby = PostgreSQL::Test::Cluster->new("standby2_$strategy");
     $node_standby->init_from_backup($node_primary, $backup_name,
         has_streaming => 1);

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup