Marek =?utf-8?q?Wi=C4=99ckowski?= <wieckom@xxxxxxx> writes: > But for the library which I'm using, simply exiting/aborting is not an option > (and this is why I was looking into this in the first place). There is a > danger that client programs will continue issuing queries while believing that > they are in a transaction... They do expect db errors and rolled back > transactions, but not that their begin-commit section would be executed only > partially. Solving this on the level of "my" library would solve it once for > good (and the alternative sounds more complex: it would require exposing extra > info to the programs using this library, and add handling of reconnect > situation in each of these programs etc.). Well, I think it's foolish to imagine that a client library should try to do transparent reconnection: it's somewhere between difficult and impossible to keep track of all the server-side state that the application might be relying on, above and beyond the immediate problem of an unfinished transaction. It's almost always better to punt the problem back to the application, and let it decide whether to try again or just curl up and die. If you have server restarts occurring often enough that this seems useful to work on, then I submit that you have problems you ought to be fixing on the server side instead. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
