On Sun, 2011-12-18 at 14:05 +1100, Chris Angelico wrote: > On Sun, Dec 18, 2011 at 2:02 PM, Chris Travers <chris.travers@xxxxxxxxx> wrote: > > I do not believe there are performance penalties for either. All > > commit or rollback does is determine visibility of changes made. > > Thanks. (And thanks for the incredibly quick response!) > > My framework has a "read-only mode" (determined by user-level access), > in which it begins a read-only transaction. At the end of it, I > currently have it rolling the transaction back (to make absolutely > sure that no changes will be made), but was concerned that this might > place unnecessary load on the system. I'll stick with rolling back, > since it's not going to hurt! > > Chris Angelico > 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
