Re: Performance question: Commit or rollback?

From: vinny <vinny(at)xs4all(dot)nl>
To: Chris Angelico <rosuav(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance question: Commit or rollback?
Date: 2011-12-24 12:46:29
Message-ID: 1324730789.6528.20.camel@vinny-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2011-12-18 at 14:05 +1100, Chris Angelico wrote:
> On Sun, Dec 18, 2011 at 2:02 PM, Chris Travers <chris(dot)travers(at)gmail(dot)com> 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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Angelico 2011-12-24 12:49:59 Re: Performance question: Commit or rollback?
Previous Message Muhammad Abuizzah 2011-12-24 09:55:30 concurrent read and write on live data feeds