Re: Strange error (Socket command option unknown)

Doug McNaught wrote:

>Carlos Moreno <moreno@mochima.com> writes:
>
>
>>I wonder if the fact that my app. is multi-threaded
>>(logging to database is something that has kind of
>>low-priority, and I don't want it to interfere with the
>>"main loop" of my app. -- the main loop is basically
>>the communications loop, which is critical for the
>>responsiveness of my server to the multiple clients).
>>
>>So, I wonder if I (or postgres??) is doing something
>>wrong with the multiple requests??  There are only
>>two threads that make any use of the database:
>>one that logs to db (i.e., exclusively insert, update,
>>and delete commands), and one to process the
>>login authentications (users' names and passwords
>>are stored in the database, along with related
>>information that has to be retrieved at login-time).
>>
>
>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++)

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.

>>So, is it possible that these two threads are "stepping
>>on each other's tails"?
>>
>
>Quite possible, unless you're taking steps to prevent it.  Sharing a
>single connection between independent threads with no locking is
>probably not going to work.
>

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)

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?

Thanks,

Carlos
--