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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
