Re: php with postgres
От | marcus.boerger@t-online.de (Marcus Börger) |
---|---|
Тема | Re: php with postgres |
Дата | |
Msg-id | 1639686082.20030723001835@post.rwth-aachen.de обсуждение исходный текст |
Ответ на | Re: php with postgres (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: php with postgres
|
Список | pgsql-hackers |
Hello Bruce, Tuesday, July 22, 2003, 10:16:53 PM, you wrote: BM> Marcus B?rger wrote: >> 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). BM> I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you BM> pass the connection to a new client. Bruce you said RESET ALL is available since 7.2. I am currently checking for the lib version but it would be more correct to check something on the server. So the question what do i check? -- Best regards,Marcus mailto:marcus.boerger@post.rwth-aachen.de
В списке pgsql-hackers по дате отправления: