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
|
| Список | 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 по дате отправления: