Re: 7.4.5 losing committed transactions
От | Tom Lane |
---|---|
Тема | Re: 7.4.5 losing committed transactions |
Дата | |
Msg-id | 7945.1096079091@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 7.4.5 losing committed transactions (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: 7.4.5 losing committed transactions
|
Список | pgsql-hackers |
Jan Wieck <JanWieck@Yahoo.com> writes: > Now the scary thing is that not only did this crash rollback a committed > transaction. Another session had enough time in between to receive a > NOTIFY and select the data that got rolled back later. Different session, or same session? NOTIFY is one of the cases that would cause the backend to emit messages within the trouble window between EndCommand and actual commit. I don't believe that that path will do a deliberate pq_flush, but it would be possible that the NOTIFY message fills the output buffer and causes the 'C' message to go out prematurely. If you can actually prove that a *different session* was able to see as committed data that was not safely committed, then we have another problem to look for. I am hoping we have only one nasty bug today ;-) regards, tom lane
В списке pgsql-hackers по дате отправления: