[pgpool-general: 969] Re: using prepared statements when memory_cache_enabled=on

[Greg Swallow]

Yep.

On Sep 6, 2012, at 1:10 PM, Lonni J Friedman wrote:

> Its somewhat encouraging knowing its not just me.  Are you seeing the
> same error that I'm seeing?
> 
> 
> On Thu, Sep 6, 2012 at 6:53 AM, Greg Swallow <gswallow at exacttarget.com> wrote:
>> I'm in the same boat, with a Rails app.  I can't reproduce it running the same query in psql, but once I turned the memory cache off, I stopped having this issue. I'm using membase and moxi, rather than memcached.  It's wire-format compatible from what I can tell.  PostgreSQL 9.1.4.  I can possibly help debug.
>> 
>> On Sep 5, 2012, at 5:26 PM, Lonni J Friedman wrote:
>> 
>>> On Tue, Sep 4, 2012 at 9:30 PM, Nozomi Anzai <anzai at sraoss.co.jp> wrote:
>>>> Hi,
>>>> 
>>>>> Greetings,
>>>>> I'm running 3.2.0 with memory_cache_enabled=on and memqcache_method =
>>>>> 'memcached', and I'm seeing really bizarre errors when using prepared
>>>>> statements.  Basically any query that should use the prepared
>>>>> statement is failing with:
>>>>> server sent data ("D" message) without prior row description ("T" message)
>>>>> 
>>>>> This only happens once the data has been cached by pgpool (with the
>>>>> memcache server).  If I set memory_cache_enabled=off, then it works
>>>>> fine.  I'm guessing that maybe the problem is that the prepared
>>>>> statement isn't getting cached, so the queries which depend on the
>>>>> prepared statement fail?
>>>>> 
>>>>> Is this expected behavior?  If so, is there a work around that doesn't
>>>>> require me to not cache the tables that the prepared statement
>>>>> reference?
>>>> 
>>>> I couldn't reproduce it by the following ways:
>>>> 
>>>> 1) the attached simple Java program: pgsql.java (only executing one SELECT)
>>>> 2) pgbench -M extended -f bench.sql
>>>> 
>>>> Which version is your PostgreSQL? I tested with pgpool-II 3.2.0
>>>> (officially released), PostgreSQL 9.1.0, and memcached 1.4.7.
>>> 
>>> postgresql-9.1.5
>>> memcached-1.4.10
>>> 
>>> However, it looks like I was mistaken when I stated that this was
>>> triggered with prepared statements.  I tried to put together a trivial
>>> test case (similar to what you created), and now I can't replicate it.
>>> So whatever is going wrong only seems to happen inside of my huge,
>>> complex web app.    FWIW, I'm using PHP, not java.  All I know is that
>>> this reproduces 100% of the time whenever memory_cache_enabled=on, and
>>> never whenever memory_cache_enabled=off.
>>> 
>>> I'm not sure how to debug this further.  Do you have any suggestions
>>> on anything that I can change with pgpool to better isolate what's
>>> going wrong?
> 

ExactTarget
Greg Swallow
System Administrator
Phone | 317 524-5250
Yahoo IM | gswallow01
Email  | gswallow at exacttarget.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2835 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20120906/d096fb8b/attachment.p7s>