Ну неплохо бы версию указать.
А чем Вам документация не понравилась? Там все прекрасно расписано по шагам
тут

После того как настроен PITR
24.3.3.1. Recovery Settings
These settings can only be made in the recovery.conf file, and apply only for the duration of the recovery. They must be reset for any subsequent recovery you wish to perform. They cannot be changed once recovery has begun.
Установить

recovery_target_time (timestamp) This parameter specifies the time stamp up to which recovery will proceed. At most one of recovery_target_time and recovery_target_xid can be specified. The default is to recover to the end of the WAL log. The precise stopping point is also influenced by recovery_target_inclusive.

8.5.1.3. Time Stamps
Valid input for the time stamp types consists of a concatenation of a date and a time, followed by an optional time zone, followed by an optional AD or BC. (Alternatively, AD/BC can appear before the time zone, but this is not the preferred ordering.) Thus:

1999-01-08 04:05:06and:

1999-01-08 04:05:06 -8:00are valid values, which follow the ISO 8601 standard. In addition, the wide-spread format:

January 8 04:05:06 1999 PSTis supported.

The SQL standard differentiates timestamp without time zone and timestamp with time zone literals by the presence of a "+" or "-". Hence, according to the standard,

TIMESTAMP '2004-10-19 10:23:54'is a timestamp without time zone, while

TIMESTAMP '2004-10-19 10:23:54+02'is a timestamp with time zone. PostgreSQL never examines the content of a literal string before determining its type, and therefore will treat both of the above as timestamp without time zone. To ensure that a literal is treated as timestamp with time zone, give it the correct explicit type:

TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
тут смотреть документацию

eddieя правильно понимаю, что это онлайн не совсем честный? то есть существует некоторый (и не такой уж и маленький) промежуток времени между commit и попаданием измений в этот самый online backup.
Нет не правильно. У вас существуют копии WAL на удаленном хосте и локальные(те которые сейчас работают). Вот совокупность этих WAL содержит все закоммиченные транзакции на текущий момент времени. Т е если у вас развалится диск с текущими WAL - соответственно вы не сможете соответственно восстановить БД на момент тех транзакций, которые в текущем WAL

зафиксированные транзакции пишуться в буфер и по чекпоинту или по заполнению страницы WAL сбрасывается на диск. Дисковый кэш соответственно живет сам по себе, поэтому включив fsync в конфиге принудительно заставляем сбрасывать и его данные на диск.
Все сказанное Вами относительно "не совсем честный" относится и к другим серверам БД - если Вы, например, выдумаете положить жруналы логов транзакций на страйп. При падении сервера Вы точно так же обретете кучу геммороя, имея при этом части(по аналогу WAL скопированные на удаленный хост) на тех серверах БД, которые позволяют делать такие конфигурации. По ним вы не восстановите те транзакции(закоммиченные), которые находятся в журнале на сломаном диске.
Поэтому размещайте журналы на RAID1 или RAID10