From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Function to know last log write timestamp |
Date: | 2014-08-11 03:42:06 |
Message-ID: | CAHGQGwFDvvLRBc2BCrVNzmmTmKTJK3OEwg-0LcWsuM12r-nnyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii <ishii(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2014-08-11 03:55:08 | Re: Hokey wrong versions of libpq in apt.postgresql.org |
Previous Message | Michael Paquier | 2014-08-11 02:54:30 | Re: Support for N synchronous standby servers |