Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-10 Thread Fujii Masao
On Sat, Sep 10, 2011 at 12:32 AM, Robert Haas wrote: > On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao 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

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-09 Thread Robert Haas
On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao 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 like a possibly p

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 10:03 PM, Robert Haas wrote: > On Thu, Sep 8, 2011 at 6:14 AM, Fujii Masao 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

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 wouldn'

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Robert Haas
On Thu, Sep 8, 2011 at 6:14 AM, Fujii Masao 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 > something like pg_last_

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 5:55 PM, Simon Riggs wrote: > On Thu, Sep 8, 2011 at 9:36 AM, Fujii Masao 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 >> reasonable to me. So I'd like to propose new

Re: [HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Simon Riggs
On Thu, Sep 8, 2011 at 9:36 AM, Fujii Masao wrote: > On Thu, Sep 8, 2011 at 7:06 AM, Chris Redekop 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

[HACKERS] pg_last_xact_insert_timestamp

2011-09-08 Thread Fujii Masao
On Thu, Sep 8, 2011 at 7:06 AM, Chris Redekop 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 > master::pg_last_xact_timestamp() - >