On 09/13/2011 04:01 AM, Aleksey Tsalolikhin wrote:
Congratulations on the release of 9.1.0!
Lots of great features, I for one can't wait to try out unlogged
tables, that should help a lot in our environment.
Now that you have streaming replication both async and sync, are you
working on multi-master replication? *excited* Or what's the
roadmap?
I haven't heard anything about multimaster, but if you're interested,
search the archives of the pgsql-hackers mailing list for discussions on it.
Personally I can't see SR being helpful as the base of an MM
implementation; it's totally reliant on the idea of one server being the
source of all WAL data. I suspect that MM would have to be a completely
different affair. I know a lot of people are dubious about MM because of
its inherent performance limitations and the difficulty of getting it to
be both correct and even vaguely fast-ish. You need shared storage or
some protocol for doing I/O via other masters; you need a network
locking protocol that handles the numerous kinds of locking required and
somehow does it fast, etc. The network locking protocol alone would be a
major effort, especially as you'd want to do optimistic locking where
possible. That's where transactions don't block, instead they fail on
commit if a conflicting transaction already committed.
Personally I'm vaguely interested in the idea of selective replication,
where some tables or databases can be omitted from replication (or even
sent to a different replication client) but still WAL-logged and
crash-safe on the master. Doing this with tablespace granularity would
possibly make sense. Pg already stores heap data as individual files,
one or more per index/table/etc, so if it could split WAL-logging out
into per-tablespace logs then some clients could elect not to carry some
tablespaces, and they could be treated as unlogged tables on that client.
That said, "vaguely interested in" means I haven't the time to even
begin learning the appropriate parts of the codebase, nor the enthusiasm
for it. I don't need the feature and don't even use SR, I just know some
others would benefit from it and have seen requests for selective
replication here before.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
