[Pgpool-general] Error in pgpool

[Glyn Astill]

Hi Tatsuo,

Great, I assumed some sort of internal table of prepared statements wasn't getting cleared out. When you said it was expected behavior it confused me.

I'm trying to patch against the pgpool-II-2.2 source, either I'm either too much of a cretin to apply it or pool_proto_modules.c has other changes?

xnagios:/usr/pgsql_src/pgpool-II-2.2# patch -p0 --verbose < DeAl22.patch
Hmm...  Looks like a new-style context diff to me...
The text leading up to this was:
--------------------------
|Index: pool_proto_modules.c
|===================================================================
|RCS file: /cvsroot/pgpool/pgpool-II/pool_proto_modules.c,v
|retrieving revision 1.6
|diff -c -r1.6 pool_proto_modules.c
|*** pool_proto_modules.c    22 Jan 2009 09:16:37 -0000    1.6
|--- pool_proto_modules.c    3 Apr 2009 10:35:48 -0000
--------------------------
Patching file pool_proto_modules.c using Plan A...
Hunk #1 FAILED at 141.
Hunk #2 FAILED at 346.
2 out of 2 hunks FAILED -- saving rejects to file pool_proto_modules.c.rej
done


I was just going to edit it by hand but then I couldn't see what was going off in the patch.  The best I could figure was that this if statement wrapping if (IsA(node, PrepareStmt)) was getting removed

if (frontend)
              {

              /////// 

              }

And the following is now getting declared a bit further up at line 141

POOL_MEMORY_POOL *old_context = NULL;
Portal *portal;

Is that correct?

Thanks
Glyn

--- On Fri, 3/4/09, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> From: Tatsuo Ishii <ishii at sraoss.co.jp>
> Subject: Re: [Pgpool-general] Error in pgpool
> To: glynastill at yahoo.co.uk, nimesh.satam at gmail.com, pgpool-general at pgfoundry.org
> Date: Friday, 3 April, 2009, 11:39 AM
> I have looked into this and found that it was actually
> caused by a bug
> (this bug has been there since pgpool-II 2.1).
> 
> When DISCARD ALL is sent, pgpool forgets all prepared
> statement in its
> internal table. Problem is, this is not done if the query
> is in
> reset_query_list. Included is a patch to solve the problem.
> Please
> try.
> 
> By this fix, now reset_query_list should be able to contain
> "DISCARD
> ALL" without any errors in PostgreSQL.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> > > It would appear that switching reset_query_list
> back from 'ABORT; DISCARD ALL' to 'ABORT; RESET
> ALL; SET SESSION AUTHORIZATION DEFAULT' stops this
> happening for us.  I'm not 100% sure yet, but since I
> changed this parameter and reloaded the configuration
> I've not seen any more of these deallocate errors.
> > 
> > That's expected behavior. DISCARD ALL conflicts
> pgpool-II's automatic
> > DEALLOCATE prepapred statements.
> > 
> > > After I reloaded pgpool I gradually saw less of
> the errors until they (appear to have) stopped, so I assume
> the updated parameter is only read by the backend when a
> client connects? 
> > 
> > Yes. Probably it should be documented somewhere
> though.
> > 
> > > I.e. I presume everyone connected before I
> reloaded issued an 'ABORT; DISCARD ALL', and anyone
> connecting afterwards would use 'ABORT; RESET ALL; SET
> SESSION AUTHORIZATION DEFAULT' ?
> > 
> > Right.
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> >