> > parse
> > bind
> > describe
> > execute
> >
> > parse invalid SQL thus abort a transaction
> > bind (error)
> > describe (error)
> > execute (crush)
> >
> > Please note that without pgpool backend does not crush. This is
> > because JDBC driver does not do execute() if prior parse, bind
> > et
On Tue, 29 Dec 2009, Tatsuo Ishii wrote:
parse
bind
describe
execute
parse invalid SQL thus abort a transaction
bind (error)
describe (error)
execute (crush)
Please note that without pgpool backend does not crush. This is
because JDBC driver does not do execute() if prior parse, bind
etc. fa
> (In any case, some kind of quick lobotomy in libpq would be easier
> than writing a standalone test program, no?)
Sounds nice idea.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Tatsuo Ishii writes:
>>> Hm, can't you get libpq to do it?
> It seems we can't get libpq to do it. libpq does not provide a
> function which can execute bind alone. In my understanding
> PQexecPrepared does bind + execute.
The event sequence you mentioned had bind followed by execute, so
I'm not
> > Hm, can't you get libpq to do it?
>
> That depends on how libpq is "intelligent":-) Let me try...
>
> Another idea is a "packet recorder", which could record packets from
> pgpool to PostgreSQL and replay them. I don't remember at present, but
> I vaguely recall something like that exists.
I
> > If you don't mind to use pgpool, it would be possible. If not, I need
> > to write a small program which handles frontend/backend protocol
> > directly. What shall I do?
>
> Hm, can't you get libpq to do it?
That depends on how libpq is "intelligent":-) Let me try...
Another idea is a "packe
Tatsuo Ishii writes:
>> Could we see an actual test case?
> If you don't mind to use pgpool, it would be possible. If not, I need
> to write a small program which handles frontend/backend protocol
> directly. What shall I do?
Hm, can't you get libpq to do it?
regards, to
> Tatsuo Ishii writes:
> > It seems the source of the problem is, exec_execute_message tries to
> > execute unamed portal which has unnamed statement which has already
> > gone.
>
> Could we see an actual test case?
If you don't mind to use pgpool, it would be possible. If not, I need
to write a
Tatsuo Ishii writes:
> It seems the source of the problem is, exec_execute_message tries to
> execute unamed portal which has unnamed statement which has already
> gone.
Could we see an actual test case?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-ha
While inspecting a complain from a pgpool user, I found that
PostgreSQL crushes with following statck trace:
#0 0x0826436a in list_length (l=0xaabe4e28)
at ../../../src/include/nodes/pg_list.h:94
#1 0x08262168 in IsTransactionStmtList (parseTrees=0xaabe4e28)
at postgres.c:2429
#2 0x0826
10 matches
Mail list logo
