Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: tracking commit timestamps
Дата
Msg-id CAHyXU0yUwWpuFgL8mfmcMCRqHLJyKjgi4SfM_L2rRBxFiQN9Bw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: tracking commit timestamps
Список pgsql-hackers
On Tue, Dec 10, 2013 at 2:48 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.

+1

It's also requested now and then in the context of auditing and
forensic analysis of application problems.  But I also agree that the
tolerance for performance overhead is got to be quite low.  If a GUC
is introduced to manage the tradeoff, it should be defaulted to 'on'.

merlin



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Reducing Catalog Locking
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Reducing Catalog Locking