DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk;
	h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=VbYOLFedrvXwfQ5CXXyWTleZasA1tnJagxs/iitfIy925zzXHU3Z7ryLpyeFFbQGiPCJTU8ElslphvFRew941/gmQPQbs49ufPoAeOglWvGgR+ZQMmYlUcN7ACsfXh4fnCGLu+DepWCOEoJxQGnqFFH72L/yE+3rkGEgeD1V+ks=;
Message-ID: <48572.83482.qm@web23605.mail.ird.yahoo.com>
Date: Fri, 20 Mar 2009 12:02:01 +0000 (GMT)
From: Glyn Astill <glynastill@yahoo.co.uk>
Reply-To: glynastill@yahoo.co.uk
Subject: Re: Prepared statement does not exist
To: Nimesh Satam <nimesh.zedo@gmail.com>
Cc: pgsql-performance@postgresql.org, Nimesh Satam <nimesh.satam@gmail.com>
In-Reply-To: <965aa3ed0903200203w75bd3b96ofdf5b080dbbdd4c2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


--- On Fri, 20/3/09, Nimesh Satam <nimesh.zedo@gmail.com> wrote:

> From: Nimesh Satam <nimesh.zedo@gmail.com>
> > > We are receving the following error in the
> postgres
> > > database logs:
> > >
> > > 2009-03-19 02:14:20 PDT [2547]: [79-1] LOG:=20
> duration:
> > > 0.039 ms  statement:
> > > RESET ALL
> > > 2009-03-19 02:14:20 PDT [2547]: [80-1] LOG:=20
> duration:
> > > 0.027 ms  statement:
> > > SET SESSION AUTHORIZATION DEFAULT
> > > 2009-03-19 02:14:20 PDT [2547]: [81-1] ERROR:=20
> prepared
> > > statement "S_1" does
> > > not exist
> > > 2009-03-19 02:14:20 PDT [2547]: [82-1] STATEMENT:
> > > DEALLOCATE "S_1"
> > > 2009-03-19 02:14:20 PDT [2547]: [83-1] ERROR:=20
> prepared
> > > statement "S_4" does
> > > not exist
> > > 2009-03-19 02:14:20 PDT [2547]: [84-1] STATEMENT:
> > > DEALLOCATE "S_4"
> > >
> > > We receive this errors when we start connecting
> the java
> > > application
> > > thorugh pgpool. What causes this problem and how
> can it be
> > > avoided?
> >
> > Looks like your app is dissconnecting from pgpool
> which is causing pgpool
> > to send the RESET ALL, this will deallocate the
> prepared statement. Then the
> > app is reconnecting to pgpool again and expecting the
> prepared statement to
> > still be available, which it will not be.
>=20
> Thank for your reply. But can you confirm on this? As what
> I see from
> the logs, its pgpool which is trying to deallocate the
> prepared
> statement and not the application. The application just
> disconnects
> and not tyring to use the same connection.

There is the possibility that it's pgpool sending the deallocate in error a=
fter the reset all then. Either way, this is not relevent to the performanc=
e list, send it over to the pgpool list... and tell them your pgpool versio=
n number too - it may be a fixed bug.=0A=0A=0A