Re: 8.2.4 signal 11 with large transaction
От | Bill Moran |
---|---|
Тема | Re: 8.2.4 signal 11 with large transaction |
Дата | |
Msg-id | 20070720131704.f76af31d.wmoran@collaborativefusion.com обсуждение исходный текст |
Ответ на | Re: 8.2.4 signal 11 with large transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 8.2.4 signal 11 with large transaction
Re: 8.2.4 signal 11 with large transaction |
Список | pgsql-general |
In response to Tom Lane <tgl@sss.pgh.pa.us>: > Bill Moran <wmoran@collaborativefusion.com> writes: > > I'm now full of mystery and wonder. It would appear as if the > > underlying problem has something to do with PHP, but why should this > > cause a backend process to crash? > > I'd bet on PHP submitting the query via extended query protocol > (PQexecParams or equivalent) instead of plain ol PQexec which is what > psql uses. Doesn't appear that way. The PHP source is somewhat cryptic, but I don't seem much ambiguity here: pgsql_result = PQexec(pgsql, Z_STRVAL_PP(query)); There're no conditional blocks around that, so it's the only possible choice when pg_query() gets called in a PHP script. PHP exposes a seperate pg_query_params() that wraps PQexecParams(). > I don't speak PHP or have it installed here, so this example > is hard for me to investigate. Can someone make a reproducer that uses > PQexecParams? Is there any way that this (or something similar) could still apply? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023
В списке pgsql-general по дате отправления: