Marek =?utf-8?q?Wi=C4=99ckowski?= <wieckom@foxi.nl> 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
