From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Aleksey Tsalolikhin <atsaloli(dot)tech(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Has Pg 9.1.0 been released today? |
Date: | 2011-09-14 01:43:21 |
Message-ID: | 4E7006B9.9080101@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2011-09-14 01:55:00 | Re: Has Pg 9.1.0 been released today? |
Previous Message | Craig Ringer | 2011-09-14 01:29:15 | Re: 8.4.4 locked after power failure |