Re: [INTERFACES] Libpq problems (not)

Dirk Elmendorf <delmendo(at)cymitar(dot)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