BUG #18069: pg_is_in_recovery() is false but recovery is not yet completed(i.e. recovery.signal is present)

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: sahul02(at)gmail(dot)com
Subject: BUG #18069: pg_is_in_recovery() is false but recovery is not yet completed(i.e. recovery.signal is present)
Date: 2023-08-25 06:40:12
Message-ID: 18069-6f70685af750e8ab@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 18069
Logged by: AK
Email address: sahul02(at)gmail(dot)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 .

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-08-25 14:00:01 BUG #18070: Assertion failed when processing error from plpy's iterator
Previous Message Zhijie Hou (Fujitsu) 2023-08-25 04:06:16 RE: BUG #18055: logical decoding core on AllocateSnapshotBuilder()