Re: Has Pg 9.1.0 been released today?
От | Craig Ringer |
---|---|
Тема | Re: Has Pg 9.1.0 been released today? |
Дата | |
Msg-id | 4E7006B9.9080101@ringerc.id.au обсуждение исходный текст |
Ответ на | Re: Has Pg 9.1.0 been released today? (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>) |
Ответы |
Re: Has Pg 9.1.0 been released today?
|
Список | 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
В списке pgsql-general по дате отправления: