| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: tracking commit timestamps |
| Date: | 2014-10-31 14:07:20 |
| Message-ID: | 30058.1414764440@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-www |
Merlin Moncure <mmoncure(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-10-31 14:08:59 | Re: group locking: incomplete patch, just for discussion |
| Previous Message | Tom Lane | 2014-10-31 14:02:28 | Re: Reducing Catalog Locking |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2014-10-31 14:31:29 | Re: tracking commit timestamps |
| Previous Message | Merlin Moncure | 2014-10-31 14:00:52 | Re: tracking commit timestamps |