Re: tracking commit timestamps - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tracking commit timestamps
Date
Msg-id 30058.1414764440@sss.pgh.pa.us
Whole thread Raw
In response to Re: tracking commit timestamps  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: tracking commit timestamps
List pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> 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'.

Alvaro's original submission specified that the feature defaults to "off".
Since there's no use-case for it unless you've installed some third-party
code (eg an external replication solution), I think that should stay true.
The feature's overhead might be small, but it is most certainly not zero,
and people shouldn't be paying for it unless they need it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reducing Catalog Locking
Next
From: Robert Haas
Date:
Subject: Re: group locking: incomplete patch, just for discussion