| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | The Hermit Hacker <scrappy(at)postgresql(dot)org> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, sailesh(at)cs(dot)berkeley(dot)edu, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mike Mascari <mascarm(at)mascari(dot)com>, Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Two weeks to feature freeze |
| Date: | 2003-06-23 05:18:26 |
| Message-ID: | 16637.1056345506@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
The Hermit Hacker <scrappy(at)postgresql(dot)org> writes:
> Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the
> co-ordinator crashes?
Or you just lose the network connection for awhile. The worst case
scenario I think is where the co-ordinator got everyone's promise to
commit, and told some of the subordinates to commit, but your own
response gets lost due to network failure. Now what? If you time
out and decide to abort, you're inconsistent with the other
subordinates. On the other hand, you can't commit after a timeout
either, because that loses in the other scenario (where the coordinator
didn't decide to commit). Basically, the subordinate must be willing
to hold its breath *forever*. I don't see how this can work.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yutaka tanida | 2003-06-23 05:32:32 | 2Q implementaion for PostgreSQL buffer replacement. |
| Previous Message | The Hermit Hacker | 2003-06-23 05:06:16 | Re: Two weeks to feature freeze |