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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
