Re: Performance question: Commit or rollback?
От | vinny |
---|---|
Тема | Re: Performance question: Commit or rollback? |
Дата | |
Msg-id | 1324731630.6528.30.camel@vinny-laptop обсуждение исходный текст |
Ответ на | Re: Performance question: Commit or rollback? (Chris Angelico <rosuav@gmail.com>) |
Ответы |
Re: Performance question: Commit or rollback?
|
Список | pgsql-general |
On Sat, 2011-12-24 at 23:49 +1100, Chris Angelico wrote: > On Sat, Dec 24, 2011 at 11:46 PM, vinny <vinny@xs4all.nl> wrote: > > The actual rollback won't hurt as long as you have not made any > > modificatons to any records. But opening the transaction could have side > > effects for other processes that want to modiy the records that you want > > to protect in your read-only transaction. > > > > How about using a databaseuser that has it's create/update/delete rights > > revoked? That will cause an error if the supposedly read-only routine > > does try to change data. > > The readonly-ness of the session is defined based on information > stored in the database, so that would entail the cost of > re-authenticating. Yes you would have to re-authenticate, you'd have to weigh the time-cost of that that against any performance hits the transaction might cause. > Also, we want to minimize debugging time by having > both read-only and read-write access use almost exactly the same code > and DB access, meaning that we should not need to test every module in > every mode. So, your read-only mode is basically a flag that forces your code to always issue a rollback at the end, instead of a commit for read/write mode. I find that a bit scary. :-) regard, Vincent.
В списке pgsql-general по дате отправления: