First I'll describe my setup just to give you some context. If anyone would like to discuss my ideas or propose their own ideas for discussion, let's do so on -ADMIN or -GENERAL.
I have multiple production database clusters which I want to make backups of. Restoring from plain dumps takes too long, so I made an almost typical continuous archiving setup. The unusual assumption in this case is that the standbys are all on a single machine and they are not always running. There are multiple $PGDATA directories on the backups machine, but only one postmaster running in standby mode, replaying archived WAL files from each master. When it's finished replaying them for one $PGDATA, it'll move to another. That way they all will be sufficiently up to date while not requiring resources needed for N replicas running all the time on a single machine. This of course requires that the standbys are never promoted, never change the timeline, etc. - they need to be able to keep replaying WAL files from the masters. I've achieved what I wanted essentially by setting standby_mode = on and restore_command = 'cp /archivedir/%f "%p" || { pg_ctl -D . stop && false ; }', but I was looking for a more elegant solution. Which brings us to the topic. One thing I tried was a combination of recovery_target_action = 'shutdown' and recovery_target_time = 'now'. The result is surprising, because then the standby tries to set the target to year 2000. That's because recovery_target_time depends on timestamptz_in(), the result of which can depend on GetCurrentTransactionStartTimestamp(). But at that point there isn't any transaction yet. Which is why I'm getting "starting point-in-time recovery to 2000-01-01 01:00:00+01". At the very least, I think timestamptz_in() should either complain about being called outside of transaction or return the expected value, because returning year 2000 is unuseful at best. I would also like to become able to do what I'm doing in a less hacky way (assuming there isn't one already but I may be wrong), perhaps once there is a new 'furthest' setting for recovery_target or when recovery_target_time = 'now' works as I expected. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers