Yes byte lag as well as it makes more sense.
Regards,
Granthana
Regards,
Granthana
On Tue, Jan 21, 2014 at 11:03 AM, Sameer Kumar wrote:
>
>>
>> We are already using the following query:
>>
>> SELECT CASE WHEN pg_last_xlog_receive_location(
>> ) = pg_last_xlog_replay_location() THEN 0 ELSE EXT
Thanks a load Michael. This is really helpful.
Regards,
Granthana
On Tue, Jan 21, 2014 at 12:19 PM, Michael Paquier wrote:
>
>
> On Tue, Jan 21, 2014 at 2:33 PM, Sameer Kumar
> wrote:
> >>
> >>
> >> We are already using the following query:
> >>
> >> SELECT CASE WHEN pg_last_xlog_receive_loc
Hi Ray,
We are already using the following 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()) END AS log_delay;
We cannot use pg_xlog_location_diff as we use postgresql 9.1.
Regards,
On Tue, Jan 21, 2014 at 2:33 PM, Sameer Kumar
wrote:
>>
>>
>> We are already using the following 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()) END AS log_delay;
>>
> Thi
>
>
>
> We are already using the following 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()) END AS log_delay;
>
> This is (delay) not the correct thing to monitor.
We cannot u
On Tue, Jan 21, 2014 at 1:30 PM, Sameer Kumar wrote:
>
> On Tue, Jan 21, 2014 at 12:12 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> Mind you, here is a simple suggestion:
>> SELECT application_name, pg_xlog_location_diff(sent_location,
>> flush_location) AS replay_delta, sync_pri
On Tue, Jan 21, 2014 at 12:12 PM, Michael Paquier wrote:
> Mind you, here is a simple suggestion:
> SELECT application_name, pg_xlog_location_diff(sent_location,
> flush_location) AS replay_delta, sync_priority, sync_state FROM
> pg_stat_replication ORDER BY replay_delta ASC, application_name;
>
On Tue, Jan 21, 2014 at 12:41 PM, Sameer Kumar wrote:
>
> On Mon, Jan 20, 2014 at 1:53 PM, Granthana Biswas wrote:
>
>> Yes we already do that. Count the number of ready wal files.
>
>
> I guess a better place to check would be pg_stat_replication
>
>
> Check this discussion:
> http://www.postgres
On Mon, Jan 20, 2014 at 1:53 PM, Granthana Biswas wrote:
> Yes we already do that. Count the number of ready wal files.
I guess a better place to check would be pg_stat_replication
Check this discussion:
http://www.postgresql.org/message-id/4f13ed11.6080...@gmail.com
Another way is explained
Yes we already do that. Count the number of ready wal files.
Regards,
Granthana
On Sat, Jan 18, 2014 at 9:39 PM, Sameer Kumar wrote:
> Well in that case monitoring pending wal bytes would make more sense.
>
> Regards
> Sameer
>
> PS: Sent from my Mobile device. Pls ignore typo n abb
>
Well in that case monitoring pending wal bytes would make more sense.
Regards
Sameer
PS: Sent from my Mobile device. Pls ignore typo n abb
On Jan 17, 2014, at 5:07 AM, Granthana Biswas wrote:
> Yes it's purely for monitoring purpose.
>
I use the pg_controldata cmd locally and via bash/ssh shared keys and compare
various values that seem interesting such as "Time of latest checkpoint, Latest
checkpoint location." My interest i
Yes it's purely for monitoring purpose.
Regards,
Granthana
On Fri, Jan 17, 2014 at 3:29 PM, Sameer Kumar wrote:
>
>
> On Fri, Jan 17, 2014 at 5:31 PM, Granthana Biswas wrote:
>
>>
>>
>> Thank you Sameer for your reply. Is there any other query that would help
>> get exact replication lag?
>>
>
Thank you Sameer for your reply. Is there any other query that would help
get exact replication lag?
Regards,
Granthana
Regards,
Granthana
On Fri, Jan 17, 2014 at 2:46 PM, Sameer Kumar wrote:
>
> On Tue, Jan 14, 2014 at 2:31 PM, Granthana Biswas wrote:
>
>> Can anyone please tell me which of t
On Fri, Jan 17, 2014 at 5:31 PM, Granthana Biswas wrote:
>
>
> Thank you Sameer for your reply. Is there any other query that would help
> get exact replication lag?
>
>
You 2nd Query is the most accurate you can get.
> 2. SELECT CASE WHEN pg_last_xlog_receive_location() =
>>> pg_last_xlog_repl
On Tue, Jan 14, 2014 at 2:31 PM, Granthana Biswas wrote:
> Can anyone please tell me which of the following is the correct
> replication lag query to find streaming replication lag in seconds?
>
> IMHO none is 'correct'. :-)
1. SELECT extract(seconds from (now() - pg_last_xact_replay_timestamp())
16 matches
Mail list logo
