On 16 Sep 2003, Abdul-Wahid Paterson wrote:
> I have kinda put my finger on the problem. It seems that a transaction
> was crashing out somewhere in my code and a rollback was not being done
> (I have not found the line of code yet) and the next PHP script to take
> on the connection was therefore getting a message saying that the
> current transaction was aborted.
>
> ...
>
> The thing that still puzzles me is this: If you remember from my earlier
> post, the only thing I have changed here is the database server (from
> postgres 7.1.3 to 7.3.4). What I don't understand is why did 7.1.3 never
> cause a problem with the failed transactions not being rolledback?
Were they failing before? I should imagine there's sufficient differences in
between 7.1.x and 7.3.x to start causing you problems if you've just blindly
assumed all queries will work exactly the same.
> Postgres surely doesn't know that it is a new PHP script using the
> connection as all Postgres knows about is the Apache HTTP process
> holding the connection open. Can anyone shed some light on the
> difference between version? Or perhaps there is something else in
> Postgres configuration that would change the above behaviour.
Use the server logs to determine what query is failing. Simple thing is it to
start at the start of the log and the first error report you find should be
the, or at least a, problem. If not then obviously you'll have to scan the
errors until you find a query you don't expect to get an error.
--
Nigel Andrews