Re: Strange error (Socket command option unknown)

Carlos Moreno <moreno(at)mochima(dot)com> writes:

> Doug McNaught wrote:
>
> >If you're using the database from two threads, you should either be
> >using one DB connection per thread, or protecting the single DB
> >connection with a mutex lock for the duration of each query. One
> >connection per thread is probably simplest.
> >
>
> Hmm, are you referring to the PgDatabase object that I
> use to connect to the database? (I'm using libpq++)

I don't know libpq++ but I would assume that each PgDatabase object
has its own underlying database connection. If this is true than you
shouldn't see any thread-related problems. You should read the
libpq++ docs and/or the source code to make sure of this, though.

> If that is what you're referring to, then yes, I'm perfectly
> fine there -- the PgDatabase object is a local variable in
> each of the two threads. Each thread loops checking
> a "jobs queue" (properly synchronized -- honest! :-)),
> and whenever it finds one or several SQL's to be
> executed (or a login to be processed), *then* it creates
> the PgDatabase object, which lives for the duration of
> that loop -- i.e., the same PgDatabase object will be
> used to execute the one or several jobs in the queue.

Creating and destroying database connections on the fly is kind of
inefficient, but shouldn't cause the problems you're seeing.

I'm wondering if it might not be a libpq++ bug, just because you don't
seem to be doing anything nonstandard otherwise, and there haven't
been any reports that I've seen of people running into this using
regular libpq, especially since you're not using COPY...

> No, that's not what is happening. But I was wondering
> if there is some information that indirectly is being shared
> by the two threads (that it is because of my mistake or
> postgres' mistake -- far less likely, of course)

As I said, it *might* be a libpq++ bug. What you say below kind of
smells like it:

> BTW, after reading Tom's message, I restarted the system
> to change the startup script and send all output from
> postmaster to a log file.
>
> Nothing relevant; there are about a dozen logged messages
> "Socket command type e unknown", and the line before is
> either another identical message, or a failed insert (a
> foreign key referential integrity violation). These failed
> inserts are not supposed to happen, but right now, it is
> happening because of a minor bug recently fixed, that
> was causing certain things not to be inserted to the DB,
> and so now the subsequent inserts are making reference
> to something that is not present. Still, this should be
> normal operation from the point of view of the server;
> it is simply an insert that failed and was properly
> reported by the backend, right?

Right. Perhaps the client-side library isn't handling it properly.

Might be time to dig in with a debugger. If you can trigger the
referential integrity violation at will, do so and step through the
libpq++ code with gdb (or whatever)--see if it handles the error from
the server properly (you'll need to read up on the wire protocol).

Good luck...

-Doug