pg_migrator issues
in [PgSql]
|
From: Robert Haas on 4 Jan 2010 15:30 On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Robert Haas wrote: >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> > Alvaro Herrera wrote: >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails >> >> > if the tablespaces are on mount points. ?I have already received a >> >> > report of such a failure. >> >> >> >> I thought it was impossible to use bare mountpoints as tablespaces due >> >> to ownership problems ... Is that not the case? ?-1 for special hacks >> >> that work around bogus setups, if that means intrusive changes to the >> >> core code. >> > >> > I talked to the person who reported the problem and he and I confirmed >> > that it is quite easy to make the mount point be owned by the postgres >> > user and have that function as a tablespace. ?Is that not a supported >> > setup? ?There is probably a larger problem that the tablespace must be >> > located in a directory that has directory rename permission for >> > postgres. ?I have updated the pg_migrator INSTALL file to mention this >> > issue. >> > >> > As far as .old, we could create the tablespaces as *.new, but that kind >> > of defeats the existing recommended pg_migrator usage where we tell the >> > user to rename PGDATA to .old before running pg_migrator. >> > >> > It was actually Tom's idea months ago to put a version-specific >> > directory in the tablespace. ?I don't think it is necessary, and we can >> > live with the mount point limitation. >> >> What doesn't work if we just don't rename the tablespace at all? And >> can't we put some smarts into the backend to handle that thing? > > Well, when you restore the old dump's schema into the new server, the > tablespace directory path will be the same, so we had better not have > any directory there. Well that seems like something you could work around by hacking the contents of the dump... ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jan 2010 15:33 Robert Haas wrote: > On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > > Robert Haas wrote: > >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > >> > Alvaro Herrera wrote: > >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails > >> >> > if the tablespaces are on mount points. ?I have already received a > >> >> > report of such a failure. > >> >> > >> >> I thought it was impossible to use bare mountpoints as tablespaces due > >> >> to ownership problems ... Is that not the case? ?-1 for special hacks > >> >> that work around bogus setups, if that means intrusive changes to the > >> >> core code. > >> > > >> > I talked to the person who reported the problem and he and I confirmed > >> > that it is quite easy to make the mount point be owned by the postgres > >> > user and have that function as a tablespace. ?Is that not a supported > >> > setup? ?There is probably a larger problem that the tablespace must be > >> > located in a directory that has directory rename permission for > >> > postgres. ?I have updated the pg_migrator INSTALL file to mention this > >> > issue. > >> > > >> > As far as .old, we could create the tablespaces as *.new, but that kind > >> > of defeats the existing recommended pg_migrator usage where we tell the > >> > user to rename PGDATA to .old before running pg_migrator. > >> > > >> > It was actually Tom's idea months ago to put a version-specific > >> > directory in the tablespace. ?I don't think it is necessary, and we can > >> > live with the mount point limitation. > >> > >> What doesn't work if we just don't rename the tablespace at all? ?And > >> can't we put some smarts into the backend to handle that thing? > > > > Well, when you restore the old dump's schema into the new server, the > > tablespace directory path will be the same, so we had better not have > > any directory there. > > Well that seems like something you could work around by hacking the > contents of the dump... True, in --binary-upgrade mode, but what do we make it? *.new? What if they want to have the same tablespace names after the upgrade? It really gets ugly if we are on a mount point because the tablespaces will be in different file systems, which makes --link mode impossible, and might create files in a filesystem that doesn't have enough space. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jan 2010 15:34 Bruce Momjian wrote: > Alvaro Herrera wrote: > > > 2) Right now pg_migrator renames old tablespaces to .old, which fails > > > if the tablespaces are on mount points. I have already received a > > > report of such a failure. > > > > I thought it was impossible to use bare mountpoints as tablespaces due > > to ownership problems ... Is that not the case? -1 for special hacks > > that work around bogus setups, if that means intrusive changes to the > > core code. > > I talked to the person who reported the problem and he and I confirmed > that it is quite easy to make the mount point be owned by the postgres > user and have that function as a tablespace. Is that not a supported > setup? There is probably a larger problem that the tablespace must be > located in a directory that has directory rename permission for > postgres. I have updated the pg_migrator INSTALL file to mention this > issue. Oh, the actual INSTALL warning is: If you are using tablespaces, there must be sufficient directory permissions to allow each tablespace directory to be renamed with a ".old" suffix. -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 4 Jan 2010 16:43 On Mon, Jan 4, 2010 at 3:33 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Robert Haas wrote: >> On Mon, Jan 4, 2010 at 2:52 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> > Robert Haas wrote: >> >> On Mon, Jan 4, 2010 at 2:11 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> >> > Alvaro Herrera wrote: >> >> >> > 2) ?Right now pg_migrator renames old tablespaces to .old, which fails >> >> >> > if the tablespaces are on mount points. ?I have already received a >> >> >> > report of such a failure. >> >> >> >> >> >> I thought it was impossible to use bare mountpoints as tablespaces due >> >> >> to ownership problems ... Is that not the case? ?-1 for special hacks >> >> >> that work around bogus setups, if that means intrusive changes to the >> >> >> core code. >> >> > >> >> > I talked to the person who reported the problem and he and I confirmed >> >> > that it is quite easy to make the mount point be owned by the postgres >> >> > user and have that function as a tablespace. ?Is that not a supported >> >> > setup? ?There is probably a larger problem that the tablespace must be >> >> > located in a directory that has directory rename permission for >> >> > postgres. ?I have updated the pg_migrator INSTALL file to mention this >> >> > issue. >> >> > >> >> > As far as .old, we could create the tablespaces as *.new, but that kind >> >> > of defeats the existing recommended pg_migrator usage where we tell the >> >> > user to rename PGDATA to .old before running pg_migrator. >> >> > >> >> > It was actually Tom's idea months ago to put a version-specific >> >> > directory in the tablespace. ?I don't think it is necessary, and we can >> >> > live with the mount point limitation. >> >> >> >> What doesn't work if we just don't rename the tablespace at all? ?And >> >> can't we put some smarts into the backend to handle that thing? >> > >> > Well, when you restore the old dump's schema into the new server, the >> > tablespace directory path will be the same, so we had better not have >> > any directory there. >> >> Well that seems like something you could work around by hacking the >> contents of the dump... > > True, in --binary-upgrade mode, but what do we make it? *.new? What if > they want to have the same tablespace names after the upgrade? It > really gets ugly if we are on a mount point because the tablespaces will > be in different file systems, which makes --link mode impossible, and > might create files in a filesystem that doesn't have enough space. 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.? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jan 2010 16:53
Robert Haas wrote: > >> >> What doesn't work if we just don't rename the tablespace at all? ?And > >> >> can't we put some smarts into the backend to handle that thing? > >> > > >> > Well, when you restore the old dump's schema into the new server, the > >> > tablespace directory path will be the same, so we had better not have > >> > any directory there. > >> > >> Well that seems like something you could work around by hacking the > >> contents of the dump... > > > > True, in --binary-upgrade mode, but what do we make it? ?*.new? ?What if > > they want to have the same tablespace names after the upgrade? ?It > > really gets ugly if we are on a mount point because the tablespaces will > > be in different file systems, which makes --link mode impossible, and > > might create files in a filesystem that doesn't have enough space. > > 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. What were you thinking this function call would do? -- Bruce Momjian <bruce(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |