Re: master-side counterpart of pg_last_xact_replay_timestamp?
От | Fujii Masao |
---|---|
Тема | Re: master-side counterpart of pg_last_xact_replay_timestamp? |
Дата | |
Msg-id | CAHGQGwFHYKTJfX9Yk1zSydEtj7RB3EPrG1HEXQt3ZBi6UqzLYw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: master-side counterpart of pg_last_xact_replay_timestamp? (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-general |
On Thu, Sep 8, 2011 at 3:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Thu, Sep 8, 2011 at 6:43 AM, Fujii Masao <masao.fujii@gmail.com> 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
В списке pgsql-general по дате отправления: