Re: Hot Standby conflict resolution handling

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Hot Standby conflict resolution handling
Дата
Msg-id CABOikdOcMSdC=L83ScqwkdctMcqRYwqnkJetFHA5=Vq-Up_KqA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hot Standby conflict resolution handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hot Standby conflict resolution handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

But having said that ... are we sure this code is not actually broken?

I'm not.
 
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly that.

I thought since FATAL will force the backend to exit, we don't care much about corrupted OpenSSL state. I even thought that's why we raise ERROR to FATAL so that the backend can start in a clean state. But clearly I'm missing a point here because you don't think that way.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

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

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: CF3+4 (was Re: Parallel query execution)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Removing PD_ALL_VISIBLE