I apologise for the duplicate posts - my initial post wasn't appearing
on the mailing list archives hours later, and someone in #postgresql
said that there was a problem with the service provider, so I thought
I'd resend.
> such an approach is doomed to failure, you have just implemented a
> race condition. what happens if the server becomes unavailable between
> the request and the response, or during the response.
It had occurred to me that this was the case. However, even though the
suggested approach is sub-optimal, it still significantly ameliorates
the problem - the server may be shut down intentionally by someone
that is not aware that the handset is being used much of the time, and
that is unlikely to occur the instant between checking the connection
is all right and using the connection. If you can suggest an
alternative approach that doesn't have a race condition, I'm all ears.
Also, maybe you should give the hyperbole a rest.
> when you shut the server down it announces this to the clients, it may
> even ask their permission before proceeding.
Yes, that too had occurred to me. I recall that Slony-I really hates
it when you cut the connection, but is fine when you shut down
PostgreSQL correctly. From the Slony-I docs : "Any problems with that
connection can kill the connection whilst leaving "zombied" database
connections on the node that (typically) will not die off for around
two hours." It doesn't necessarily follow that my program should die
though, but it does. My guess is that libpq is calling abort() or
something similar, directly or indirectly. I know that would cause an
error message with windows XP, but windows CE is funny.
> you are not checking the return values from some of your libpq calls.
The only thing that I don't check the return value of is PQreset,
which returns void. What do you mean?
Regards,
Peter Geoghegan