Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-10 Thread Fujii Masao
On Sat, Sep 10, 2011 at 12:32 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao masao.fu...@gmail.com wrote: Another idea to avoid spinlock contention is save the timestamp in PgBackendStatus (which contains information for pg_stat_activity). This enables

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-09 Thread Robert Haas
On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao masao.fu...@gmail.com wrote: Another idea to avoid spinlock contention is save the timestamp in PgBackendStatus (which contains information for pg_stat_activity). This enables us to write and read the timestamp without spinlock. Comments? That seems

[HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 7:06 AM, Chris Redekop ch...@replicon.com wrote: 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

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Simon Riggs
On Thu, Sep 8, 2011 at 9:36 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Sep 8, 2011 at 7:06 AM, Chris Redekop ch...@replicon.com wrote: Is there anything available to get the last time a transaction occurred?like say pg_last_xact_timestamp?  In order to accurately calculate how

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 5:55 PM, Simon Riggs si...@2ndquadrant.com wrote: On Thu, Sep 8, 2011 at 9:36 AM, Fujii Masao masao.fu...@gmail.com wrote: The above has been posted in pgsql-general. The reason why Chris thinks a counterpart of pg_last_xact_replay_timestamp() is required sounds

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Robert Haas
On Thu, Sep 8, 2011 at 6:14 AM, Fujii Masao masao.fu...@gmail.com wrote: OTOH, new function enables users to monitor the delay as a timestamp. For users, a timestamp is obviously easier to handle than LSN, and the delay as a timestamp is more intuitive. So, I think that it's worth adding

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Chris Redekop
Thanks for all the feedback guys. Just to throw another monkey wrench in here - I've been playing with Simon's proposed solution of returning 0 when the WAL positions match, and I've come to the realizatiion that even if using pg_last_xact_insert_timestamp, although it would help, we still

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 10:03 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Sep 8, 2011 at 6:14 AM, Fujii Masao masao.fu...@gmail.com wrote: OTOH, new function enables users to monitor the delay as a timestamp. For users, a timestamp is obviously easier to handle than LSN, and the delay