Re: pg_migrator issues
От | Bruce Momjian |
---|---|
Тема | Re: pg_migrator issues |
Дата | |
Msg-id | 201001042214.o04ME0119257@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_migrator issues (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas wrote: > >> But can't we just call a special function first before running the > >> CREATE TABLESPACE, like: > >> > >> pg_tablespace_dont_really_create_this_tablespace_because_we_are_in_pg_migrator()? > >> > >> Sorta like what you did to preserve ENUM OIDs, etc.? > > > > Well, the problem is that we are creating something in a file system, > > and the old and new contents of the tablespace directories must exist > > after the migration (in case the migration is reverted). ?We were able > > to get away with this for enum because we were only creating this in the > > _new_ database. ?With the file system, we have a resource/namespace > > shared between the old and new server. > > Oh, I thought you were hard-linking the files, not copying them, so > the old directory would be destroyed anyway. The default mode is COPY but there is a --link option. You are right that if we only did linking things would be much simpler. > > What were you thinking this function call would do? > > Basically, make PostgreSQL not reinitialize the directory as it > normally would when a new tablespace is created. Or make it ignore > the existence of the directory until told to stop ignoring it. Or > whatever is needed to avoid having to move the thing around. Sorry, > I'm hand-waving wildly here; I haven't read the code. Maybe I should > shut up. Sorry, I can't figure out how that would work. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: