Re: Clustering features for upcoming developer meeting -- please claim yours!
От | Marko Kreen |
---|---|
Тема | Re: Clustering features for upcoming developer meeting -- please claim yours! |
Дата | |
Msg-id | AANLkTinJmo-KGEQ0RQmzojKkOcTlcDYjSQ4GBsF2TFqU@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Clustering features for upcoming developer meeting -- please claim yours! (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Clustering features for upcoming developer
meeting -- please claim yours!
|
Список | pgsql-cluster-hackers |
On 5/10/10, Jan Wieck <JanWieck@yahoo.com> wrote: > On 5/10/2010 1:39 PM, Josh Berkus wrote: > > > Aside from that list, I'd like to get into a little more detail on DDL > > > triggers. This seems to be something I could actually work on in the > > > future. > > > > > > > Is this the same thing as the general modification trigger? > > > > To my understanding, the general modification triggers are meant to unify > the "data" queue mechanisms, both Londiste and Slony are based on, under one > new, built in mechanism with the intention to cut down the overhead > associated with them. > > There is certainly a big need to coordinate this project with any attempts > made in the direction of DDL triggers. I think it is obvious that I would > later on like to make use of them within Slony to replicate schema changes. > This of course requires that such schema changes get applied on the > replica's at the correct place inside the data stream. For example, if you > "ALTER TABLE ADD COLUMN", you want to replicate all DML changes, that > happened before that ALTER TABLE grabbed its exclusive lock, before that > ALTER TABLE itself. And it would be quite disastrous to attempt to apply any > INSERT that happened on the master with that new column before the ALTER > TABLE happened on the replica. AFAICS the "agreeable order" should take care of positioning: http://wiki.postgresql.org/wiki/ModificationTriggerGDQ#Suggestions_for_Implementation This combined with DML triggers that react to invalidate events (like PgQ ones) should already work fine? Are there situations where such setup fails? -- marko
В списке pgsql-cluster-hackers по дате отправления: