| From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at> |
| Cc: | Theo Schlossnagle <jesus(at)omniti(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Jim Nasby <decibel(at)decibel(dot)org> |
| Subject: | Re: Proposal: Commit timestamp |
| Date: | 2007-02-06 16:44:33 |
| Message-ID: | 45C8B071.8090401@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Zeugswetter Andreas ADI SD wrote:
> And "time based"
> is surely one of the important conflict resolution methods for async MM
> replication.
That's what I'm questioning. Wouldn't any other deterministic, but
seemingly random abort decision be as clever as time based conflict
resolution? It would then be clear to the user that it's random and not
some "in most cases time based, but no in others and only if..." thing.
> Sure there are others, like "rule based" "priority based" but I think
> you don't need additional backend functionality for those.
Got the point, yes. I'm impatient, sorry.
Neither the less, I'm questioning if is it worth adding backend
functionality for that. And given this probably is the most wanted
resolution method, this question might be "heretical". You could also
see it as sort of an user educating question: don't favor time based
resolution if that's the one resolution method with the most traps.
Regards
Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Sullivan | 2007-02-06 16:46:24 | Re: Modifying and solidifying contrib |
| Previous Message | Andrew Dunstan | 2007-02-06 16:43:24 | Re: Modifying and solidifying contrib |