On Tue, Dec 10, 2013 at 2:48 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
