Re: Rod Taylor
От | Rod Taylor |
---|---|
Тема | Re: Rod Taylor |
Дата | |
Msg-id | 1117123579.3769.262.camel@home обсуждение исходный текст |
Ответ на | Rod Taylor (Narasimha.Sridhar@cybernetsoft.com) |
Список | pgsql-hackers |
> >At the VERY LEAST, you'd best get off 7.2.1 to something later (i.e. > >the last 7.2 release). ISTR some nasty bug or other in 7.2.1. > > I heard for Andrew Sullivan that you managed to hack Slony-I to work > for postgre 7.2. > Can you tell me how you did as it would me helpful to me I no longer have the code, but (from memory) this is approximately what you need to do: * Take the 7.3 templates and copy them to 7.2 -- or otherwise hardcode the version your using to pick up the 7.3templates * Remove all traces of schemas from the code and sql templates. I basically changed the "." to an"_". * Bunch of work related to the XID datatype and functions. For example, Slony creates CASTs for the xidto xxid and back -- but 7.2 cannot create new casts that way so you need to edit system tables by hand. Irecall creating an Operator Class and editing several functions as well. * sl_log_1 will have severe performanceproblems with any kind of data volume. This required a number of index and query changes to optimizefor 7.2. 7.3 and above are quite a bit smarter in terms of optimizations they can apply. * Don't bothertrying to make sequences work. Do them by hand after the upgrade using pg_dump and grep. Of course, now that you have done all of the above, it's not compatible with standard Slony now. So you either need to implement 7.2 in a less hackish way, or you can also hack up slony to work without schemas on newer versions of PostgreSQL so they can talk to each other. Almost immediately after getting the DB upgraded from 7.2 to 7.4, we deinstalled the hacked up Slony (by hand for the most part), and started a migration from 7.4 to 7.4 on a different machine using the regular Slony. This was primarily to ensure we didn't keep our system catalogues which had been manually fiddled with. All that said, we upgraded a few hundred GB from 7.2 to 7.4 with about 30 minutes actual downtime (versus 48 hours for a dump / restore cycle) and no data loss. --
В списке pgsql-hackers по дате отправления: