BUG #18069: pg_is_in_recovery() is false but recovery is not yet completed(i.e. recovery.signal is present) - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #18069: pg_is_in_recovery() is false but recovery is not yet completed(i.e. recovery.signal is present)
Date
Msg-id 18069-6f70685af750e8ab@postgresql.org
Whole thread Raw
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      18069
Logged by:          AK
Email address:      sahul02@gmail.com
PostgreSQL version: 15.2
Operating system:   Debian Ubuntu
Description:

created a backup_label and tablespace_map file 
-rw-r--r--  1 postgres postgres    34 Aug 24 15:27 tablespace_map
-rw-r--r--  1 postgres postgres     0 Aug 24 15:27 recovery.signal
-rw-r--r--  1 postgres postgres   205 Aug 24 15:27 backup_label
Contents of the files are:
backup-label:
----------------
START WAL LOCATION: 0/6000028 (file 000000010000000000000006)
CHECKPOINT LOCATION: 0/6000060
BACKUP METHOD: streamed
BACKUP FROM: primary
START TIME: 2023-08-24 14:09:58 IST
LABEL: label
START TIMELINE: 1
tablespace_map
----------------------
16384 /pgsql/pg15_edb/tsdata/data

postgres log says ....
2023-08-24 15:25:13 IST LOG:  database system was interrupted; last known up
at 2023-08-24 14:09:58 IST
2023-08-24 15:25:13 IST LOG:  database system was not properly shut down;
automatic recovery in progress
2023-08-24 15:25:13 IST LOG:  redo starts at 0/6000028
2023-08-24 15:25:13 IST LOG:  invalid record length at 0/6000110: wanted 24,
got 0
2023-08-24 15:25:13 IST LOG:  redo done at 0/60000D8 system usage: CPU:
user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2023-08-24 15:25:13 IST LOG:  checkpoint starting: end-of-recovery immediate
wait
2023-08-24 15:25:13 IST LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0
WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.002 s,
total=0.027 s; sync files=2, longest=0.002 s, average=0.001 s; distance=0
kB, estimate=0 kB
2023-08-24 15:25:13 IST LOG:  database system is ready to accept
connections

but the recovery.signal is present still. and backup_label and
tablespace_map file has not renamed yet to backup_label.old and
tablespace_map.old.

Actually i have scipt which basically create backup_label and tablespace_map
file under the source data directory  and try to run recovery using PITR.
My script log says:
Thu 24 Aug 2023 03:27:19 PM IST :: Checking recovery status...  1
Thu 24 Aug 2023 03:27:19 PM IST :: Recovery status: i.e. psql -t -c "SELECT
pg_is_in_recovery() is f.
Thu 24 Aug 2023 03:27:19 PM IST :: Recovery complete

the timing is 15:27:19PM .. but the log timing is around 15.25:13 ...lag of
2 minutes. 
Question is why the recovery.log file is still present and the
backup_label.old and tablespace_map.old not available if the recovery is
already completed.i.e. psql -t -c "SELECT pg_is_in_recovery() output is  f .


pgsql-bugs by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: BUG #18055: logical decoding core on AllocateSnapshotBuilder()
Next
From: PG Bug reporting form
Date:
Subject: BUG #18070: Assertion failed when processing error from plpy's iterator