From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Carlos Moreno <moreno(at)mochima(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Still intrigued... (was: Socket command type e unknown) |
Date: | 2003-02-26 23:34:32 |
Message-ID: | 7302.1046302472@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Carlos Moreno <moreno(at)mochima(dot)com> writes:
> What I observed is the following: message from FE
> to BE, data: Qinsert into table ......
> Then a reply Pblank.CINSERT.304712345
> (I guess the number is the OID of the record inserted).
That looks fine.
> After that, another message from FE to BE, with an X
> (which is "close connection", if I understand correctly).
> But then, *after* sending that one, the client sends
> another block, starting with an e, or a p. Bang!!
> That's my error.
An X message? The backend should drop the connection and shut down
upon seeing X --- it'll never get as far as noticing the following data.
I think either you misinterpreted the tcp dump, or else things are
already out of sync at that point.
> Of course, in my code, I simply do:
> if (db.Exec (sql_string) != PGRES_COMMAND_OK)
I had not realized that you are using libpq++. It's entirely likely
that the bug is in libpq++ ... that's not the best-written part of the
Postgres universe :-(, and it doesn't get nearly as much testing as,
say, libpq. Still, a quick look at Exec() doesn't reveal any obvious
way that it could do more than the intended PQexec().
I think you need to start digging in libpq++.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-26 23:47:55 | Re: Is renaming a database easy or dangerous |
Previous Message | Jonathan Bartlett | 2003-02-26 23:32:25 | Filesystem solution for database redundancy |