Re: php with postgres - Mailing list pgsql-hackers

From marcus.boerger@t-online.de (Marcus Börger)
Subject Re: php with postgres
Date
Msg-id 1798645481.20030722215412@post.rwth-aachen.de
Whole thread Raw
In response to Re: php with postgres  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Hello Jan,

Tuesday, July 22, 2003, 1:28:18 PM, you wrote:

JW> Marcus Börger wrote:
>> 
>> Here's the current log while reusing the persistent connection:
>> 
>> DEBUG:  InitPostgres
>> DEBUG:  StartTransactionCommand
>> DEBUG:  query: select getdatabaseencoding()
>> DEBUG:  ProcessQuery
>> DEBUG:  CommitTransactionCommand
>> DEBUG:  StartTransactionCommand
>> DEBUG:  query: RESET ALL
>> DEBUG:  ProcessUtility: RESET ALL
>> DEBUG:  CommitTransactionCommand
>> DEBUG:  StartTransactionCommand
>> DEBUG:  query: BEGIN;ROLLBACK;
>> DEBUG:  ProcessUtility: BEGIN;ROLLBACK;
>> DEBUG:  CommitTransactionCommand
>> DEBUG:  StartTransactionCommand
>> DEBUG:  ProcessUtility: BEGIN;ROLLBACK;
>> DEBUG:  CommitTransactionCommand
>> DEBUG:  pq_recvbuf: unexpected EOF on client connection
>> 

JW> And this is the wrong order of things. The BEGIN;ROLLBACK; has to be 
JW> done first, otherwise if the connection was left in an aborted open 
JW> transaction by the previous script, the other two actions will fail.


Yeah well it seems i gave a wrong impression what is actually happening now.
We don't handle any transaction at the moment but starting with the second
call to pg_pconnect on the same db we do RESET ALL. The following log is from
a three connections, so you can see two RESET ALL.

DEBUG:  BackendStartup: forked pid=28253 socket=8
LOG:  query: select getdatabaseencoding()
LOG:  query: RESET ALL
LOG:  query: RESET ALL
LOG:  query: BEGIN;ROLLBACK;
LOG:  unexpected EOF on client connection

However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with persistent conenctions
in a multithreaded environment isn't the best thing you could do. So our
options are
1) tell the users to do 'auto commit mode'
2) nested transactions
3) locking

From my perspective 2) and 3) are bad ideas for the web environment. In other
words i guess we should leave it as is with transaction rollback only when the
client terminates (e.g. the webserver stops).


Best regards,Marcus                            mailto:marcus.boerger@post.rwth-aachen.de



pgsql-hackers by date:

Previous
From: Dennis Gearon
Date:
Subject: Re: [GENERAL] Checkpoints
Next
From: marcus.boerger@t-online.de (Marcus Börger)
Date:
Subject: Re: php with postgres