On Thu, 2005-05-26 at 22:53 +0200, Paul J Stevens wrote:
> I was just under the impression that a certain amount of diversion doesn't
> affect the usability of the system. It just affects it's level of correctness,
> and it's cheaper.
Nope. IMAP clients are allowed to take advantage of the fact that UID
numbers are always increasing. If a new message comes in it MUST NOT
have a UID number lower than a UID number the client has already seen.
> >
> > 1. Pg supports SEQUENCEs. Even with replication these will never
> > collide.
> >
> > 2. SQLite supports single files only, so this is moot.
> >
> > 3. MySQL supports sequences as well- older versions might have an issue,
> > but those versions won't support replication _either_.
>
> This whole discussion started from the assumption that mysql's auto_increment
> fields may very well collide in a clustered multi-master environment.
I wasn't suggesting the use of mysql's auto_increment- but it would
require transactions. You need transactions (anyway) if you're doing
replication, so that's not an unreasonable requirement.
Fortunately, if auto_increment were also UNIQUE I would consider it a
bug in MySQL if it allowed the UNIQUE constraint to be violated just
because of replication.
Does MySQL even support native replication. Is this worth it? Pg and
Oracle support native replication, maybe an Oracle patch would be
useful :)
> >
> > So it would seen that the best method is to have a :
> >
> > int db_get_next_sequence(const char *d, unsigned int *e);
> >
> > function. It returns 0 if sequence space is exhausted (and UIDVALIDITY
> > needs updating and reodering, etc). *e will contain the resulting uid
> > number if db_get_next_sequence() returns nonzero.
> >
> > d is a "domain" string- and is essentially the "sequence name". This
> > would be unique per mailbox per user.
> >
> >
>
> Again, I don't see how that addresses the problem at hand. Maybe you're so far
> ahead here, you're out of sight :)
The need is unique values that are useful as UID numbers, correct? They
must conform to RFC2060 which means they have certain requirements.
The replication that we can support (and still support RFC2060) is one
of:
* single-master
* single-lock
There are no other kinds of replication possible (unless this UID
requirement could go away).
{{ if you need to see why, I'm happy to explain- but it's quite
wordy :) }}
single-master is what openldap does- you have one node that makes
changes and pushes it out to slaves which are read-only.
single-lock means that when a resource is taken, the other replicants
are made aware and not allowed to touch that data. essentially we have a
serialized step. GFS and Oracle do this. PostgreSQL should be able to do
this.
now, we actually need FULL synchrony on a mailbox when inserting a
message because those UID numbers must NEVER EVER jump backwards.
this is why multi-master lockless synchronization is impossible.
If the DB can't provide this- that is- if mysql really can break UNIQUE
referential integrity (during replication), then we should toss UIDs
altogether - make the UID==ID and set the UIDVALIDITY to the unique-
identifier as you suggest (host number+timestamp)
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
