Re: Re: Disk acces
От | Bruce Momjian |
---|---|
Тема | Re: Re: Disk acces |
Дата | |
Msg-id | 200102011844.NAA11043@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Disk acces ("Mitch Vincent" <mitch@venux.net>) |
Ответы |
Re: Re: Disk acces
|
Список | pgsql-general |
[ Charset ISO-8859-1 unsupported, converting... ] > Hi Doug, your comments caught my eye and I thought I'd ask you something.. > Are you speaking of using persistant connections with PHP? I'm not sure what > Enhydra is, so forgive me if this is totally off base.. > > We do a lot of development in PHP and only use PostgreSQL, I've tried and > tried to get persistant connections to work but every time I use them, very > strange things start to happen (variables disappearing and getting corruted > to name one).. It was said a while back on the list that the most probable > reason for that is that PHP isn't thread safe and that was probably the > cause.. Another strange, though not surprising thing that happens is that if > you begin a transaction in a PHP script and the script is terminated before > you comit or rollback (be that from the user clicing stop or a script/server > error), the transaction is left open for the next time that backend is > used -- it's caused a lot of problems.. I say it's not surprising because > that's exactly what I'd expect to happen, there just doesn't seem to be much > of a way to prevent it in some cases.. I've tried the ignore_user_abort but > it still happened quite a lot. (I'm spoiled with Ruby and ensure :-) ).. > > Have you had those kinds of problems and if so how did you overcome them? > Does Enhydra manage your database/web server pool? I just talked to PHP/Rasmus yesterday, and I will try to get this fixed in the PHP PostgreSQL code soon. It involves adding the ability to ROLLBACK before handing the connection to a new user. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: