From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Two Phase Commit WAS: Re: Two weeks to feature freeze |
Date: | 2003-06-23 17:27:04 |
Message-ID: | 1953.1056389224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> No. I want to know what the subordinate does when it's promised to
>> commit and the co-ordinator never responds. AFAICS the subordinate
>> is screwed --- it can't commit, and it can't abort, and it can't expect
>> to make progress indefinitely on other work while it's holding locks
>> for the not-quite-committed transaction.
> Anyway, I would vote for a first implemenation for 2PC which addressed the
> commit-then-crash issue in some expedient-but-not-reliable way, and putting
> 2PC in /contrib with a "not for production use" warning. Some people will
> use it in production anyway, and hopefully one or more of them will put in
> the dozens of hours required to make it reliable.
Putting in "dozens of hours" is not the issue here --- the problem is
that there isn't any solution in sight, and I'm not eager to go down a
path that has an obvious dead end.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-06-23 17:34:27 | Re: dblink_ora - a first shot on Oracle ... |
Previous Message | scott.marlowe | 2003-06-23 16:56:07 | Re: Two weeks to feature freeze |