Re: tracking commit timestamps - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: tracking commit timestamps
Date
Msg-id CAHyXU0yUwWpuFgL8mfmcMCRqHLJyKjgi4SfM_L2rRBxFiQN9Bw@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: tracking commit timestamps
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reducing Catalog Locking
Next
From: Tom Lane
Date:
Subject: Re: Reducing Catalog Locking