Re: [INTERFACES] Libpq problems (not)

Dirk Elmendorf <delmendo@cymitar.net> writes:

I have a program which opens two connections to two different databases.
After issuing a few commands to the second database I this get in the
trace log:

To backend> QSELECT oid FROM order_table WHERE customer_number=936 ;

From backend> N
From backend> "NOTICE: SIMarkEntryData: cache state reset

This is the *second* backend sending that notice, right?

Then I get a SIGPIPE on the first database which courrpts my connection.
The funny thing is that PQstatus still says I have a good connection.

SIGPIPE implies that the first backend closed the connection. I take it
you are trapping and ignoring the SIGPIPE in your application, because
libpq doesn't. (6.3.2 libpq is not very good about dealing with
unexpected closure of the connection by the backend, which is why
PQstatus doesn't know anything's wrong. The current sources should be
much better. But that's not what your problem is anyway.)

I assume you don't actually see the SIGPIPE until you next try to send
a command to the first backend, right?

Does anything appear in your postmaster's log file when this happens?

The second database continues plugging along. I cannot seem to figure
out how to stop this - if I re-issuse all the SQL in psql each command
works like a charm - but when I do it through libpq I can not seem to
escape the problem - Has anyone else run into this problem? Can anyone
explain what this Notice means? I searched through the Mailing lists
and found a number of emails asking the same quesiton- but no answer
could be found. Any insight would be greatly appreciated. I'm
running 6.3.2 on RH 4.2

I tried opening the first db grabbing some info and then closing the
connection- then I open the second databse- I'm still able to
generate this error.

The NOTICE is coming out of some code dealing with invalidating shared
caches (src/backend/storage/ipc/sinvaladt.c). I'm cc'ing this to the
hackers list because I think you are looking at a backend bug. Most
probably, the first backend is coredumping when the second one tries to
reset the shared cache.

I run multiple backends all the time and I've never seen this happen,
so I suspect it's got some dependency on your system environment.
Anyone else using RH 4.2?

regards, tom lane