The only explanation for this is that the recovery process never saw a BACKUP_END WAL entry, that is, it never read a WAL segment that contains the effect of a pg_stop_backup call.

Now you argue convincingly that you have run the function, otherwise you wouldn't have the backup_label file that is generated by this function in a non-exclusive backup.

Archive recovery won't allow you to skip over a WAL segment during recovery, so it is impossible that that happened.

That leaves a few explanations:

1. You used a backup_label file from some other backup because something got mixed up.

2. You restored a WAL segment with the same name from a different cluster that did not contain the BACKUP_END entry.

3. You got mixed up with timelines, and there was a timeline switch during the backup, so the BACKUP_END is actually in 00000003000545210000008D or so.

   (I am not sure if that is possible or if a timeline switch will break an online backup; I didn't test.)

If everything is like you expect it to be, then 00000002000545210000008D must contain a BACKUP_END entry. Verify that with

pg_waldump 00000002000545210000008D | grep BACKUP_END

As soon as this entry is processed, PostgreSQL will emit the log line

consistent recovery state reached

The only explanation for this is that the recovery process never saw a BACKUP_END WAL entry, that is, it never read a WAL segment that contains the effect of a pg_stop_backup call.

Now you argue convincingly that you have run the function, otherwise you wouldn't have the backup_label file that is generated by this function in a non-exclusive backup.

Archive recovery won't allow you to skip over a WAL segment during recovery, so it is impossible that recovery skipped that segment.

That leaves a few explanations:

1. You used a backup_label file from some other backup because something got mixed up.

2. You restored a WAL segment with the same name from a different cluster that did not contain the BACKUP_END entry.

3. You got mixed up with timelines, and there was a timeline switch during the backup, so the BACKUP_END is actually in 00000003000545210000008D or so.

   (I am not sure if that is possible or if a timeline switch will break an online backup; I didn't test.)

If everything is like you expect it to be, then 00000002000545210000008D must contain a BACKUP_END entry. Verify that with

pg_waldump 00000002000545210000008D | grep BACKUP_END

As soon as this entry is processed, PostgreSQL will emit the log line

consistent recovery state reached