From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | recovery_target_time and standby_mode |
Date: | 2014-11-06 00:32:24 |
Message-ID: | 545AC198.6060400@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hackers,
Someone brought me an issue that recovery_target_time and standby_mode
weren't working as they expected. I think that the way they work now
makes sense, but we do need to clarify it in the docs. However, I'm
posting this to hackers first in case the way these two work together
*isn't* as intended.
Setup: two servers are restored from the same pgBarman archive. The
master is brought to a specific point in time using
recovery_target_time. Then they user attempts to do the same with the
new replica.
recovery.conf:
recovery_target_time = 'SOME-PAST-TIMESTAMP'
standby_mode = on
primary_conninfo = 'host=mymaster user=postgres port=5432'
How It Works Now:
When the recovery_target_time is reached, standby_mode is ignored and
the server comes up as a standalone.
How The User Wanted It To Work:
When the recovery_target_time is reached, switch to streaming
replication and stay a standby.
Note that there is a workaround for what the user wants to do. I'm just
trying to clarify what our desired behavior is. From there we can
either work on patches or on doc fixes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2014-11-06 00:33:29 | Re: B-Tree index builds, CLUSTER, and sortsupport |
Previous Message | Steve Singer | 2014-11-06 00:31:52 | Re: tracking commit timestamps |