On Thu, Sep 8, 2011 at 3:19 PM, Simon Riggs <simon@xxxxxxxxxxxxxxx> wrote: > On Thu, Sep 8, 2011 at 6:43 AM, Fujii Masao <masao.fujii@xxxxxxxxx> wrote: >> Your complaint makes sense. I'll implement something like >> pg_last_xact_timestamp() for 9.2. But unfortunately there is >> no way to know such a timestamp on the master, in 9.1.. > > > I see the reason, but would be against that change. > > We don't currently generate a timestamp for each WAL record. Doing so > would be a performance drain and a contention hotspot. Each commit/abort record already has a timestamp. So I'm thinking to implement pg_last_xact_insert_timestamp() so that it returns the timestamp of the last inserted commit/abort record. Since we don't need to generate a timestamp newly, I guess that what I'm thinking to implement would not degrade a performance. pg_last_xact_replay_timestamp() also returns the timestamp of the commit/abort record replayed. So pg_last_xact_insert_timestamp() doesn't need to return the timestamp other than that of commit/abort record, to compare them to calculate the replication delay. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
