Re: temporal support patch
От
Jeff Davis
Тема
Re: temporal support patch
Дата
Msg-id
1345523625.30161.28.camel@jdavis
Ответ на
Re: temporal support patch (David Johnston)
Список
Дерево обсуждения
temporal support patch Miroslav Šimulčík <simulcik.miro@gmail.com>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Vlad Arkhipov <arhipov@dc.baikal.ru>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Robert Haas <robertmhaas@gmail.com>
Re: temporal support patch "David Johnston" <polobo@yahoo.com>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch David Fetter <david@fetter.org>
Re: temporal support patch Josh Berkus <josh@agliodbs.com>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Craig Ringer <ringerc@ringerc.id.au>
Re: temporal support patch Craig Ringer <ringerc@ringerc.id.au>
Re: temporal support patch Vlad Arkhipov <arhipov@dc.baikal.ru>
Re: Audit Logs WAS: temporal support patch Josh Berkus <josh@agliodbs.com>
Re: Audit Logs WAS: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Audit Logs WAS: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: Audit Logs WAS: temporal support patch Gavin Flower <GavinFlower@archidevsys.co.nz>
Re: Audit Logs WAS: temporal support patch Vlad Arkhipov <arhipov@dc.baikal.ru>
Re: Audit Logs WAS: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: Audit Logs WAS: temporal support patch Jim Nasby <jim@nasby.net>
Re: Audit Logs WAS: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: Audit Logs WAS: temporal support patch Jim Nasby <jim@nasby.net>
Re: Audit Logs WAS: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: Audit Logs WAS: temporal support patch Christopher Browne <cbbrowne@gmail.com>
Re: Audit Logs WAS: temporal support patch Josh Berkus <josh@agliodbs.com>
Re: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: temporal support patch Gavin Flower <GavinFlower@archidevsys.co.nz>
Re: temporal support patch Alvaro Herrera <alvherre@2ndquadrant.com>
Re: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: temporal support patch Robert Haas <robertmhaas@gmail.com>
Re: temporal support patch "David Johnston" <polobo@yahoo.com>
Re: temporal support patch Robert Haas <robertmhaas@gmail.com>
Re: temporal support patch Jim Nasby <jim@nasby.net>
Re: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: temporal support patch Robert Haas <robertmhaas@gmail.com>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: temporal support patch Miroslav Šimulčík <simulcik.miro@gmail.com>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Vlad Arkhipov <arhipov@dc.baikal.ru>
Re: temporal support patch Jeff Davis <pgsql@j-davis.com>
Re: temporal support patch Merlin Moncure <mmoncure@gmail.com>
Re: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: temporal support patch Miroslav Šimulčík <simulcik.miro@gmail.com>
Re: temporal support patch Pavel Stehule <pavel.stehule@gmail.com>
Re: temporal support patch Miroslav Šimulčík <simulcik.miro@gmail.com>
Re: temporal support patch Jaime Casanova <jaime@2ndquadrant.com>
Re: temporal support patch "Albe Laurenz" <laurenz.albe@wien.gv.at>
Re: temporal support patch Miroslav Šimulčík <simulcik.miro@gmail.com>
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
В списке pgsql-hackers по дате отправления