On Fri, Dec 07, 2018 at 03:45:59PM +0900, myungkyu.lim wrote:
> Thank you for your attention!
And committed. There was one thing that the patch was doing wrong:
there is no point to convert the timestamp to a string if no log message
is generated, so I have added a check on log_min_messages to
>I have let this stuff cool down for a couple of days, still it seems to me
>that having one single column makes the most sense when it comes when
>looking at a mostly idle system. I'll try to finish this one at the
>beginning of next week, for now I am marking as ready for committer.
Thank you
On Tue, Dec 04, 2018 at 04:24:25PM +0900, myungkyu.lim wrote:
> I think purpose of this field,
> that react interval check and debugging on idle system.
> So, merging both is better.
I have let this stuff cool down for a couple of days, still it seems to
me that having one single column makes
>> I have been looking at this patch more in-depth, and you missed one
>> critical thing: hot standby feedback messages also include the
>> timestamp the client used when sending the message, so if we want to
>> track the latest time when a message has been sent we should track it
>> as much as
On Tue, Dec 04, 2018 at 12:56:25PM +0900, Michael Paquier wrote:
> I have been looking at this patch more in-depth, and you missed one
> critical thing: hot standby feedback messages also include the timestamp
> the client used when sending the message, so if we want to track the
> latest time
On Fri, Nov 30, 2018 at 05:54:15PM +0900, Michael Paquier wrote:
> Looks pretty to me at quick glance, unfortunately I have not spent much
> time on it, particularly testing it.
>
> +
> + reply_time
> + timestamp with time zone
> + Send time of last message received from WAL
>
On Thu, Nov 29, 2018 at 05:43:26PM +0900, myungkyu.lim wrote:
> Changed field name 'last_msg_send_time' to 'reply_time'.
Looks pretty to me at quick glance, unfortunately I have not spent much
time on it, particularly testing it.
+
+ reply_time
+ timestamp with time zone
+ Send
>On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
>> So I selected 'reply_time' because 'timestamp' was not used in stat
>> field.
>
>Fine by me. Could you send a new patch please? I am switching the patch
as
>waiting on author for now.
Ok.
Changed field name 'last_msg_send_time'
On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
> So I selected 'reply_time' because 'timestamp' was not used in stat
> field.
Fine by me. Could you send a new patch please? I am switching the
patch as waiting on author for now.
--
Michael
signature.asc
Description: PGP
On Thu, Nov 15, 2018 at 5:27 PM Michael Paquier wrote:
>> Good point. 'last_reply_send_time' is better.
>> How about just 'reply_time'?
>
>Please note that the original thread has mentioned reply_timestamp as a
>consensus:
So I selected 'reply_time' because 'timestamp' was not used in stat
On Thu, Nov 15, 2018 at 05:33:26PM +0900, Masahiko Sawada wrote:
> Yeah, I also agree with 'reply_time'. But please also note that we had
> the discussion when there is not the similar system catalogs and
> fields. Now that we have them it might be worth to consider to follow
> the existing name
On Thu, Nov 15, 2018 at 5:27 PM Michael Paquier wrote:
>
> On Thu, Nov 15, 2018 at 05:02:31PM +0900, myungkyu.lim wrote:
> >> I got confused by the field name. If we have 'last_msg_send_time'
> >> field in pg_stat_replciation which has information of wal senders
> >> users would think it as a
On Thu, Nov 15, 2018 at 05:02:31PM +0900, myungkyu.lim wrote:
>> I got confused by the field name. If we have 'last_msg_send_time'
>> field in pg_stat_replciation which has information of wal senders
>> users would think it as a time when the wal sender sent a message last
>> time. However values
Hi.
>> I changed field name from 'reply_time' to 'last_msg_send_time'.
>> Because 'last_msg_send_time' is used in
>> pg_stat_wal_receiver/pg_stat_subsctiption view.
>> I think that field has the same meaning.
>
>I got confused by the field name. If we have 'last_msg_send_time'
>field in
Hi.
Thanks for your feedback.
> Can you explain the purpose of this feature more because now we have columns
> to report replication delay times like write_lag ,flush_lag and replay_lag
> that can use for similar purpose .
I think, time elapsed stats are very useful on DML query active system,
Hi .
On Tue, Jul 31, 2018 at 11:57 AM MyungKyu LIM
wrote:
>
> Feedback and suggestion will be very welcome.
>
Can you explain the purpose of this feature more because now we have
columns to report replication delay times like write_lag ,flush_lag and
replay_lag that can use for similar purpose
Thanks for your feedback and info!
I registered patch in commit fest.
https://commitfest.postgresql.org/20/1841/
For the record, replied on original thread.
Best regards,
Myungkyu, Lim
-Original Message-
From: Michael Paquier [mailto:mich...@paquier.xyz]
Sent: Thursday, October 25,
entry creation timestamp column to
pg_stat_replication
MyungKyu LIM wrote:
> I have worked on following todo list item.
>
> - Add entry creation timestamp column to pg_stat_replication
> http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php
>
> This item
MyungKyu LIM wrote:
> I have worked on following todo list item.
>
> - Add entry creation timestamp column to pg_stat_replication
> http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php
>
> This item looks like simple because necessary data was already exist.
> So, I wrote a
19 matches
Mail list logo
