Re: 8.2.4 signal 11 with large transaction

On 7/20/07, Bill Moran <wmoran(at)collaborativefusion(dot)com> wrote:
> In response to Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> > Bill Moran <wmoran(at)collaborativefusion(dot)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?

I just ran your script, and only changed the connect string to reflect
my environment.

It ran smoothly against my workstations 8.1.8 pgsql install and
against my reporting server's 8.2.4 installation, inserting 30001 rows
in each.

I'm not familiar with the host=/tmp bit in the connect string, is that
an explicit declaration of using unix local sockets and the directory
to find it? Does it work if you go to tcp/ip sockets and use a
hostname etc... in your pg_connect?