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 13:00:30
Message-ID: 1324731630.6528.30.camel@vinny-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)xs4all(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Angelico 2011-12-24 13:20:03 Re: Performance question: Commit or rollback?
Previous Message Shankar Palaniappan 2011-12-24 12:54:04 Re: Unable to connect to PostgreSQL server : Could not get socket error status