>
> I hope this solves the problem.
>
> On Thu, Dec 8, 2011 at 4:57 PM, Scott Mead wrote:
>
>>
>> On Thu, Dec 8, 2011 at 4:27 PM, Bruce Momjian wrote:
>>
>>> Joshua D. Drake wrote:
>>> >
>>> > On 12/08/2011 12:57 PM, Bruce Momjian wrote:
Is there any way to get the database system identifier via a select
statement? I have a primary/secondary async replication setup, and I'd
like be able to verify from the client side that the provided primary and
secondary connection strings do in fact refer to the same data set...
>
> Caveat #2 applies here
>
> http://developer.postgresql.org/pgdocs/postgres/hot-standby.html#HOT-STANDBY-CAVEATS
>
> The consistent state is delayed until your long running transactions
> end, which is workload dependent but transient.
>
I'm not quite sure how this correlates to what I'm seeing
Is there anything available to get the last time a transaction
occurred?like say "pg_last_xact_timestamp"? In order to accurately
calculate how far behind my slave is I need to do something like
master::pg_last_xact_timestamp() -
slave::pg_last_xact_replay_timestamp()currently I'm using no
7;latest')
On Wed, Sep 7, 2011 at 6:28 AM, Alex Lai wrote:
> Chris Redekop wrote:
>
>>
>>
>>I have two questions:
>>(1) Did you set recovery_target_timeline='**latest' in both master
>>and slave?
>>
>>
>> Yesbut
>
>
> I have two questions:
> (1) Did you set recovery_target_timeline='**latest' in both master and
> slave?
>
Yesbut it's in recovery.conf so it only really applies to whichever
server is currently the slave...
> (2) Did you make any changes after promote the slave to be master?
Yes, som
I have a master+slave set up using asynchronous streaming replication. If I
do a graceful (-fast) shutdown of the master, and then promote the slave to
master, my understanding is that I should not have any data loss. At that
point in order to bring the old master back up as a slave the docs say
