pg_migrator issues
in [PgSql]
|
From: Bruce Momjian on 4 Jan 2010 14:11 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. -- 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: Tom Lane on 4 Jan 2010 14:30 Bruce Momjian <bruce(a)momjian.us> writes: > I was just really asking if disallowing pg_resetxlog -n on a live server > is planned behavior or an oversight. I can see the logic that it should > be disallowed but I am just looking for confirmation from someone and I > can then drop the issue. Well, it's not only a matter of "are we going to clobber live state", it's also "is the state that we are looking at changing under us?". The -n switch only covers the first point. I think it would require some careful analysis, and testing that's never been done, before having any confidence in the results of pg_resetxlog on a live server. Why should you need this anyway? pg_migrator should not be having to run pg_resetxlog on the old installation, I would think. regards, tom lane -- 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 14:40 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? ....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 14:51 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > I was just really asking if disallowing pg_resetxlog -n on a live server > > is planned behavior or an oversight. I can see the logic that it should > > be disallowed but I am just looking for confirmation from someone and I > > can then drop the issue. > > Well, it's not only a matter of "are we going to clobber live state", > it's also "is the state that we are looking at changing under us?". > The -n switch only covers the first point. I think it would require > some careful analysis, and testing that's never been done, before having > any confidence in the results of pg_resetxlog on a live server. Yea, that was my analysis too. I will discard the idea and just keep the pg_migrator code that does either. > Why should you need this anyway? pg_migrator should not be having to > run pg_resetxlog on the old installation, I would think. Well, the same code is run on the new and old server. The complex issue is that the same code that checks for matching controldata settings (check mode) is the same that pulls the xid from the old server to set it on the new one. -- 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 14:52
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. -- 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 |