Re: Function to know last log write timestamp
От | Fujii Masao |
---|---|
Тема | Re: Function to know last log write timestamp |
Дата | |
Msg-id | CAHGQGwFDvvLRBc2BCrVNzmmTmKTJK3OEwg-0LcWsuM12r-nnyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Function to know last log write timestamp (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: Function to know last log write timestamp
|
Список | pgsql-hackers |
On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii <ishii@postgresql.org> wrote: >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii <ishii@postgresql.org> wrote: >>> We can know the LSN of last committed WAL record on primary by using >>> pg_current_xlog_location(). It seems there's no API to know the time >>> when the WAL record was created. I would like to know standby delay by >>> using pg_last_xact_replay_timestamp() and such that API. >>> >>> If there's no such a API, it would be useful to invent usch an API IMO. >> >> +1 >> >> I proposed that function before, but unfortunately it failed to be applied. >> But I still think that function is useful to calculate the replication delay. >> The past discussion is >> http://www.postgresql.org/message-id/CAHGQGwF3ZjfuNEj5ka683KU5rQUBtSWtqFq7g1X0g34o+JXWBw@mail.gmail.com > > I looked into the thread briefly and found Simon and Robert gave -1 > for this because of performance concern. I'm not sure if it's a actual > performance penalty or not. Maybe we need to major the penalty? I think that the performance penalty is negligible small because the patch I posted before added only three stores to shared memory per commit/abort. No time-consuming operations like lock, gettimeofday, etc were added. Of course, it's worth checking whether the penalty is actually small or not, though. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: