Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: tracking commit timestamps
Дата
Msg-id CA+TgmoYXm7JcZge-iF6y5ZFF2SZ1iDQXWg40L5TD7Yp7zkeobg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: tracking commit timestamps
Re: tracking commit timestamps
Список pgsql-hackers
On Tue, Dec 10, 2013 at 4:56 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Generally speaking, I'm not in favor of adding dead code, even if it might
> be useful to someone in the future. For one, it's going to get zero testing.
> Once someone comes up with an actual use case, let's add that stuff at that
> point. Otherwise there's a good chance that we build something that's almost
> but not quite useful.

Fair.

> Speaking of the functionality this does offer, it seems pretty limited. A
> commit timestamp is nice, but it isn't very interesting on its own. You
> really also want to know what the transaction did, who ran it, etc. ISTM
> some kind of a auditing or log-parsing system that could tell you all that
> would be much more useful, but this patch doesn't get us any closer to that.

For what it's worth, I think that this has been requested numerous
times over the years by numerous developers of replication solutions.
My main question (apart from whether or not it may have bugs) is
whether it makes a noticeable performance difference.  If it does,
that sucks.  If it does not, maybe we ought to enable it by default.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: plpgsql_check_function - rebase for 9.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql_check_function - rebase for 9.3