Skip site navigation (1) Skip section navigation (2)

Re: taking actions on rollback (PHP)

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: taking actions on rollback (PHP)
Date: 2008-04-27 09:26:33
Message-ID: 20080427092633.GA6816@svana.org (view raw or flat)
Thread:
Lists: pgsql-general
On Sun, Apr 27, 2008 at 11:09:36AM +0200, Ivan Sergio Borgonovo wrote:
> > because each page got an error in a statement inside its
> > transaction. It then issued the above error over and over as you
> > attempted to execute the next statement.
> 
> That would make postgresql a BIG BIG BIG lock.
> If every rollback is going to block all connections that's a problem.
> That's exactly why I pointed out that I was using plain pg_connect
> and not pg_pconnect (pooled connection).

Eh? Each page got an error in its own transaction. An error in one
transaction naturally does not affect any other concurrent
transactions.

> I think the code would work even this way:
> if( !pg_query("select 1") )
> // commit even if failed just to signal end of transaction
>   pg_query("commit');
>   // DO CLEANUP HERE
> }

True, for an aborted transaction COMMIT and ROLLBACK do the same thing.

> Still... why did I get
> ERROR:  current transaction is aborted, commands ignored until end of
> transaction block
> from *another page* even if I was not using pg_pconnect?
> What is the state of the DB after the first failed statement?

That other page also got an error. Given then you never check the
return result of any of the queries I suggest you look at the server
logs: any statements that caused an error should be logged.

> Furthermore... what's going to happen if I use pg_pconnect?
> Managing transactions is going to become much harder.
> Is there a chance something like this is going to happen?

There's a reason why pg_pconnect is not recommended. The usual method
is some kind of connection pooling that understands transactions.

> > So, there's no "cleanup" to do for the transaction, it's already
> > cleaned up.
> 
> That would be great if the framework I'm working with would be
> transactional. So there are things done before my transaction that
> still need cleanup.

It's unclear to me what kind of cleanup you're talking about, so I
can't help you here.

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog(at)svana(dot)org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

pgsql-general by date

Next:From: Ivan Sergio BorgonovoDate: 2008-04-27 12:05:16
Subject: Re: taking actions on rollback (PHP)
Previous:From: Ivan Sergio BorgonovoDate: 2008-04-27 09:09:36
Subject: Re: taking actions on rollback (PHP)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group