How does the recovery strategy of PostgreSQL exactly work?

I'm testing and trying to figure out how the backup and recovery strategy in PostgreSQL 11 works but it does not work as expected. When I recover the backup, I don't get the correct state. I get any state after a given timestamp. In detail:

I have this setup in database:

wal_level = replica 
max_wal_senders = 10
archive_mode = on

I have executed the following commands:

postgres=# select pg_create_physical_replication_slot('slot1');
pg_basebackup -D /media/extern/postgresql_basebackup/
pg_receivewal -D /media/extern/postgresql_archive -S slot1 -v

pg_receivewal is writing into postgresql_archive, this seems to work.

• then I insert something into the database, let's say at 16:21.

• I wait some minutes, let's say until 16:27 and delete all the insert.

Then I want to recover the inserts by doing...

service postgresql stop

(do I need to stop pg_receivewal as well)?

# mv main main.before_recovery
# cp -rp /media/extern/postgresql_basebackup main

nano /var/lib/postgresql/11/main/recovery.conf

I add the following content

restore_command = 'cp -r /media/extern/postgresql_archive/%f %p'
recovery_target_time='2018-01-06 16:22:00'

Then I execute

# chown postgres:postgres recovery.conf 
# chmod 700 recovery.conf 

service postgresql start

After startup, the file changes to recovery.done, but the state in database is wrong. It didn't restore the data. The database is still empty, so the PITR didn't work, why?

What should I do In case if everything was successful after recovery?. I'm unsure about these questions:

• Creating a new slot2 by executing pg_create_physical_replication_slot('slot2'); and streaming from this slot by pg_receivewal -D /media/extern/postgresql_archive -S slot2 -v?

• Doing a pg_receivewal -D /media/extern/postgresql_archive -S slot1 -v again?

• Do I have to delete anywhen any data in postgresql_archive? (-> Probably not)

• When do I have to create another base backup?

• When and why do I

recovery_target_time='2018-01-06 16:22:00'

This 2019, not 2018. If you look in the server log file, you will probably find the recovery stopped as soon as it could (as soon as it reached a consistent state), because it could not stop as soon as you told it to, being a year late for that.

StackExchange Database Administrators Q#226449, answer score: 2