Re: [GENERAL] pg_last_xact_replay_timestamp lies

2015-06-15 Thread Anton
use this query: SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())::INTEGER END AS replication_lag; found at

[GENERAL] pg_last_xact_replay_timestamp lies

2015-06-14 Thread Anton Bushmelev
Hello, dear guru =) help me to fix situation when no change made on primary and standby show lag more than 15 minutes: master : postgres=# select * from pg_stat_replication ; -[ RECORD 1 ]+-- pid | 18553 usesysid | 117942 usename |

Re: [GENERAL] pg_last_xact_replay_timestamp lies

2015-06-14 Thread Michael Paquier
On Mon, Jun 15, 2015 at 9:04 AM, Anton Bushmelev djeda...@gmail.com wrote: Hello, thank t for response, measure in bytes may bemore correct, but to bring it to the customer? :) I think it is easier to say that the standby database lags behind master no more than 15 minutes, than the fact that

Re: [GENERAL] pg_last_xact_replay_timestamp lies

2015-06-14 Thread Michael Paquier
On Mon, Jun 15, 2015 at 8:30 AM, Anton Bushmelev djeda...@gmail.com wrote: Hello, dear guru =) help me to fix situation when no change made on primary and standby show lag more than 15 minutes: master : postgres=# select * from pg_stat_replication ; -[ RECORD 1

Re: [GENERAL] pg_last_xact_replay_timestamp lies

2015-06-14 Thread Anton Bushmelev
Hello, thank t for response, measure in bytes may bemore correct, but to bring it to the customer? :) I think it is easier to say that the standby database lags behind master no more than 15 minutes, than the fact that it differs for 1 megabyte. ps: sorry for my English On 06/15/2015 02:57