From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | David Johnston <polobo(at)yahoo(dot)com> |
Cc: | 'Robert Haas' <robertmhaas(at)gmail(dot)com>, 'Vlad Arkhipov' <arhipov(at)dc(dot)baikal(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: temporal support patch |
Date: | 2012-08-21 04:33:45 |
Message-ID: | 1345523625.30161.28.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2012-08-20 at 19:17 -0400, David Johnston wrote:
> Ideally the decision of whether to do so could be a client decision. Not
> storing intra-transaction changes is easier than storing all changes. At
> worse you could stage up all changed then simply fail to store all
> intermediate results within a given relation. It that case you gain nothing
> in execution performance but safe both storage and interpretative resources.
> So the question becomes is it worth doing without the ability to store
> intermediate results? If you were to ponder both which setup would the
> default be? If the default is the harder one (all statements) to implement
> then to avoid upgrade issues the syntax should specify that it is logging
> transactions only.
I think the biggest question here is what guarantees can be offered?
What if the transaction aborts after having written some data, does the
audit log still get updated?
> I see the "user" element as having two components:
I think this is essentially a good idea, although as I said in my other
email, we should be careful how we label the application-supplied
information in the audit log.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2012-08-21 04:52:51 | Re: temporal support patch |
Previous Message | Jeff Davis | 2012-08-21 04:24:29 | Re: temporal support patch |