PITR and moving objects between table spaces
От | Glen Parker |
---|---|
Тема | PITR and moving objects between table spaces |
Дата | |
Msg-id | 457DFCFA.3050706@nwlink.com обсуждение исходный текст |
Ответ на | Re: Marking indexes out of date (WAS: loading data, creating indexes, clustering, vacuum) feature request? (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: PITR and moving objects between table spaces
|
Список | pgsql-general |
Gurus, I hope I can make this clear somehow... Anyway... This all involves PG 8.1.4 on a 64-bit FC5 box. Select version() says "PostgreSQL 8.1.4 on x86_64-redhat-linux-gnu, compiled by GCC x86_64-redhat-linux-gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)". I guess the best question I can see is, under what circumstances is the directory name in pg_tablespace actually used? I have a scenario where I want to restore from a PITR backup, into an alternate location on the same machine it came from, while the original database is still up and running. I have one alternate table space. It goes like this. First I expand the base archive into an alternate location, then expand the table space archive(s) into alternate location(s). Then I recreate the links under pg_tblspc. I then fiddle a little bit with config files and run postgres on the new alternate location. Everthing goes fine, the database rolls forward, and then postgres quits (because I give it an SQL file for stdin). Great. But now I have a problem. What if I move objects from the main tablespace to the alternate one, such as indexes, between the time of the backup and the restore? During the restore/recovery, the pg_tablespace table is out of date. If the tablespace directory listed there was used in copying files, I'd have a big fat mess involving a badly broken production database. Hopefully that all makes sense... -Glen
В списке pgsql-general по дате отправления: