Thread: Still intrigued... (was: Socket command type e unknown)

After following your advice and tap on the communications
between frontend and backend  (I must say it was a bit
intimidating, but I did have a lot of fun), things are
very weird.

My current working theory is that all the commands are
being executed properly, despite a mysterious random
data exchange that produces the error I'm seeing.

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).

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.

Of course, in my code, I simply do:

if (db.Exec (sql_string) != PGRES_COMMAND_OK)
{
    cerr << "Error at ... currentdate ...."
         << db.ErrorMessage() << endl;
}

So, apparently Exec is internally doing more than it
should, and by the time it comes back to the calling
function, it carries the error message corresponding to
the spurious block, after having succesfully executed
the statement).

Sounds familiar to anyone out there?  Any sane reason
why this could be happening??

This sounds like the typical symptoms of a case of
undefined behaviour -- some lost pointers and the
like...  Except that I practically use no pointers at
all (all of them are encapsulated anyway...  I use
*strictly* string class, vector, list, and map -- there
is not *a single* use of any pointer in the classical
sense of using pointers -- i.e., pointer manipulation
of data structures, raw allocation, pointer arithmetic,
etc.).  Can you think of other explanations?

Thanks!

Carlos
--

Carlos Moreno <moreno@mochima.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

Is this by any chance MS Vcc :-) Maybe there's an error in the STL library.

2/26/2003 2:56:27 PM, Carlos Moreno <moreno@mochima.com> wrote:

>
>After following your advice and tap on the communications
>between frontend and backend  (I must say it was a bit
>intimidating, but I did have a lot of fun), things are
>very weird.
>
>My current working theory is that all the commands are
>being executed properly, despite a mysterious random
>data exchange that produces the error I'm seeing.
>
>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).
>
>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.
>
>Of course, in my code, I simply do:
>
>if (db.Exec (sql_string) != PGRES_COMMAND_OK)
>{
>    cerr << "Error at ... currentdate ...."
>         << db.ErrorMessage() << endl;
>}
>
>So, apparently Exec is internally doing more than it
>should, and by the time it comes back to the calling
>function, it carries the error message corresponding to
>the spurious block, after having succesfully executed
>the statement).
>
>Sounds familiar to anyone out there?  Any sane reason
>why this could be happening??
>
>This sounds like the typical symptoms of a case of
>undefined behaviour -- some lost pointers and the
>like...  Except that I practically use no pointers at
>all (all of them are encapsulated anyway...  I use
>*strictly* string class, vector, list, and map -- there
>is not *a single* use of any pointer in the classical
>sense of using pointers -- i.e., pointer manipulation
>of data structures, raw allocation, pointer arithmetic,
>etc.).  Can you think of other explanations?
>
>Thanks!
>
>Carlos
>--
>
>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>

Dennis Gearon wrote:

>Is this by any chance MS Vcc :-) Maybe there's an error in the STL library.
>

Oh c'mon now!  I'm a serious guy!!  All this is happening
on the Linux realm  :-)

Still, we are talking about a RedHat 7.3 distro, with the
original compiler (i.e., the "non-stable" version 2.96...)
So, who knows...  Compiler bug??  :-)

(actually, the last piece that I would suspect is the
compiler -- according to the comp.os.linux.development
guys, 2.96 is actually rather stable, even if it doesn't
have the seal from its developers)

Oh well...  I'll go dig a little bit in libpq++ ...

Thanks!  And thanks Tom, for your message!

Carlos
--