Re: auto-reconnect: temp schemas, sequences, transactions

Поиск
Список
Период
Сортировка
От Marek Więckowski
Тема Re: auto-reconnect: temp schemas, sequences, transactions
Дата
Msg-id 201105121558.19760.wieckom@foxi.nl
обсуждение исходный текст
Ответ на Re: auto-reconnect: temp schemas, sequences, transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hi,

Just to sum things up:

On Wednesday 04 May 2011 19:21:42 Tom Lane wrote:
> 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.

After sleeping on it - I now agree 100%. (A simple example would be
savepoints... The idea to try to create "trans in error" was silly, I must
say.)

> 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.

Yes. I dug into it a bit more and I have found the magic place where the
library which I'm using did a silent reconnection in the background. Now I
think this is the place which is wrong - if connection is not re-established
applications have a chance to notice that something went wrong and react
appropriately (do a proper clean-up, or reconnect, or abort etc.).

> 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.

Agreed. For your information, it does not happen that often, but when it did
(once in two years...) was scary enough to trigger an investigation.

Tom, thank you very much for your help!

Best,
~Marek

В списке pgsql-general по дате отправления:

Предыдущее
От: "James B. Byrne"
Дата:
Сообщение: How to handle bogus nulls from ActiveRecord
Следующее
От: vladaman
Дата:
Сообщение: Custom Data Type size - too big overhead?