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

Lonni J Friedman netllama at gmail.com
Wed Sep 12 23:29:10 JST 2012


The lack of response isn't comforting.  There's clearly a bug
somewhere, and the only way it reproduces is when using pgpool with
memcache enabled.  Does no one on the pgpool team care about this
problem?

On Mon, Sep 10, 2012 at 7:33 AM, Lonni J Friedman <netllama at gmail.com> wrote:
> Nozomi, we'd appreciate some input & assistance.  thanks!
>
> On Thu, Sep 6, 2012 at 10:12 AM, Greg Swallow <gswallow at exacttarget.com> wrote:
>> 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?
>>>


More information about the pgpool-general mailing list