This is now: https://commitfest.postgresql.org/4/128/
On Thu, Jan 29, 2015 at 7:01 PM, Matt Kelly <mkell...@gmail.com> wrote: > Robert, I'll add it to the commitfest. > > Jim, I'm not sure I understand what you mean? This new function follows > the same conventions as everything else in the file. TimestampTz is just a > typedef for int64. Functions like pg_stat_get_buf_alloc follow the exact > same pattern on the int64 fields of the global stats struct. > > - Matt K. > > On Thu, Jan 29, 2015 at 6:49 PM, Jim Nasby <jim.na...@bluetreble.com> > wrote: > >> On 1/28/15 11:18 PM, Matt Kelly wrote: >> >>> In a previous thread Tom Lane said: >>> >>> (I'm also wondering if it'd make sense to expose the stats timestamp >>> as a callable function, so that the case could be dealt with >>> programmatically as well. But that's future-feature territory.) >>> >>> (http://www.postgresql.org/message-id/27251.1421684...@sss.pgh.pa.us) >>> >>> It seemed the appropriate scope for my first submission, and that >>> feature has been on my wish list for a while, so I thought I'd grab it. >>> >> >> I've reviewed the patch (though haven't tested it myself) and it looks >> good. The only thing I'm not sure of is this: >> >> + /* Get the timestamp of the current statistics snapshot */ >> + Datum >> + pg_stat_snapshot_timestamp(PG_FUNCTION_ARGS) >> + { >> + PG_RETURN_TIMESTAMPTZ(pgstat_fetch_global()->stats_timestamp); >> + } >> >> Is the community OK with referencing stats_timestamp that way? >> -- >> Jim Nasby, Data Architect, Blue Treble Consulting >> Data in Trouble? Get it in Treble! http://BlueTreble.com >> > >
