Re: php with postgres

From: Thomas Swan <tswan(at)idigx(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Marcus Börger <marcus(dot)boerger(at)post(dot)rwth-aachen(dot)de>, 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 17:03:10
Message-ID: 3F1D6E4E.5010604@idigx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/22/2003 11:18 AM, scott.marlowe wrote:

>On Mon, 21 Jul 2003, Bruce Momjian wrote:
>
>
>
>>Jan Wieck wrote:
>>
>>
>>>Bruce Momjian wrote:
>>>
>>>
>>>>Marcus B?rger wrote:
>>>>
>>>>
>>>>>BM> Marcus, would you check if PHP is using RESET ALL when passing
>>>>>BM> persistent connection to new clients? We added that capability a few
>>>>>BM> releases ago, specifically for PHP persistent connections, but I don't
>>>>>BM> think that ever got into the PHP code.
>>>>>
>>>>>Unfortunately we don't do so yet. Do i need to check for errors or can i do it
>>>>>unconditionally on conenction start? And i'd need to know how to check if it
>>>>>is available (like starting with which version).
>>>>>
>>>>>
>>>>It first appeared in PostgreSQL version 7.2. It doesn't generate any
>>>>failures. It just resets all SET settting to their defaults, in case
>>>>the previous client modified them.
>>>>
>>>>
>>>>
>>>It does generate the usual error if the current transaction block is in
>>>ABORT state. So the correct querystring to send would be something like
>>>
>>> "ROLLBACK; RESET ALL"
>>>
>>>
>>Oh, I remember that now as part of the persistent connection code. As I
>>remember, we told them to do BEGIN;COMMIT; to clear any open transaction
>>state passed to the new client. Is that in there? If not, it has to be
>>added too. ROLLBACK will generate an error if you are not in a
>>transaction, so it would fill the logs with errors.
>>
>>
>
>Won't that break when we have nested transactions implemented? i.e.
>begin;commit; would just open a sub transaction and have no effect on the
>outer transaction...
>
>
I was just about to mention that one. Perhaps a ROLLBACK ALL would be
of benefit to allow a clean state and start to work again.

Doesn't autocommit behavior affect this as well?

>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2003-07-22 17:18:43 reprise on Linux overcommit handling
Previous Message Bruce Momjian 2003-07-22 16:58:32 Beta date on Monday?