| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 7.4.5 losing committed transactions |
| Date: | 2004-09-25 02:24:51 |
| Message-ID: | 7945.1096079091@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 2004-09-25 02:49:33 | Re: 7.4.5 losing committed transactions |
| Previous Message | Rod Taylor | 2004-09-25 02:03:36 | Possible Optimization? |