Sean Chittenden wrote:
> > > db.transaction do |dbh|
> > > db.do('DELETE FROM tbl WHERE id = 5')
> > > db['AutoCommit'] = true
> > > end
> > >
> > > Because there wasn't a commit given, that shouldn't actually
> > > delete the rows found, but by tossing that AutoCommit in there, it
> > > should and will generate a nifty warning if AutoCommit sends the
> > > above BEGIN/SET/COMMIT. -sc
> >
> > You can't be setting autocommit willy-nilly. What I was going to
> > suggest is that we allow 'SET autocommit' only at the start of a
> > transaction, and then have it take effect immediately. If you try
> > autocommit when a transaction is already in progress from a previous
> > statement, we throw an error.
>
> But that'd result in at least two transactions per connection because
> in my database class wrapper I turn autocommit off. Under any kind of
> load or performance situations, that's pretty unacceptable. Granted
> there's nothing that would need to be flushed to disk (hopefully), it
> still strikes me that there would have to be some locking involved and
> that would degrade the performance of the entire system.
You would never see a performance hit. It doesn't dirty any buffers or
anything. Heck, a SET with autocommit on is already in its own
transaction.
> If you're throwing an error in the middle of a transaction just
> because of 'SET autocommit', aren't you already making an exception
> and one that degrades the performance of the entire system as a
> result?
I think if we special case autocommit we have to force it to start a
transaction.
> I just saw Tom's post and it seems like something has to give
> someplace... I'm not a fan of the idea of creating the special case,
> don't get me wrong, but is there a reasonable alternative? -sc
I am willing to special case autocommit because it is so tied to
transactions anyway.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
