Re: php with postgres

From: marcus(dot)boerger(at)t-online(dot)de (Marcus Brger)
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, ivan <iv(at)psycho(dot)pl>, Joe Conway <mail(at)joeconway(dot)com>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: php with postgres
Date: 2003-07-22 19:54:12
Message-ID: 1798645481.20030722215412@post.rwth-aachen.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)boerger(at)post(dot)rwth-aachen(dot)de

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Francisco Figueiredo Jr. 2003-07-22 19:54:21 Re: Why select * from function doesn't work when function
Previous Message Nigel J. Andrews 2003-07-22 19:28:13 Re: Why select * from function doesn't work when function