pg_migrator issues
in [PgSql]
|
From: Tom Lane on 5 Jan 2010 00:24 Bruce Momjian <bruce(a)momjian.us> writes: > 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. If we implicitly added "/8.5" etc at the end of the specified tablespace path, the problems go away. 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: Bruce Momjian on 5 Jan 2010 10:27 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Alvaro Herrera wrote: > >> 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? > > It might be *possible*, but that doesn't make it a good idea. The > traditional sysadmin advice in this area is that mount points should > be owned by root. I don't really remember the reasoning but I'm pretty > sure I remember the principle. Yea, I think the logic is that files under that directory disappear after the mount, so you don't want users putting things in there accidentally. In fact, the user said they mount a pg_xlog directory under the $PGDATA directory (rather than use a symlink), which I also thought was an odd approach and prone to problems if the mount failed intermittently. > > It was actually Tom's idea months ago to put a version-specific > > directory in the tablespace. > > I was just about to re-suggest that. Why do you think it's such a > bad idea? I liked the idea, but I listed it as item #2 and no one else said they liked it. The only complexity I can see with the idea is that doing an upgrade from one alpha to another would have the same major version number and would therefore not be possible, so maybe we have to use the catalog version number in 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
From: Tom Lane on 5 Jan 2010 10:53 Bruce Momjian <bruce(a)momjian.us> writes: > I liked the idea, but I listed it as item #2 and no one else said they > liked it. The only complexity I can see with the idea is that doing an > upgrade from one alpha to another would have the same major version > number and would therefore not be possible, so maybe we have to use the > catalog version number in there. Good point. Using catversion for the purpose seems a bit ugly but I have no better ideas. 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: Alvaro Herrera on 5 Jan 2010 11:06 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > I liked the idea, but I listed it as item #2 and no one else said they > > liked it. The only complexity I can see with the idea is that doing an > > upgrade from one alpha to another would have the same major version > > number and would therefore not be possible, so maybe we have to use the > > catalog version number in there. > > Good point. Using catversion for the purpose seems a bit ugly but > I have no better ideas. I thought we had rejected the idea of being able to migrate between alphas. Is migrating between major versions not difficult enough? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 5 Jan 2010 11:08
On Tue, Jan 5, 2010 at 11:06 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Tom Lane wrote: >> Bruce Momjian <bruce(a)momjian.us> writes: >> > I liked the idea, but I listed it as item #2 and no one else said they >> > liked it. The only complexity I can see with the idea is that doing an >> > upgrade from one alpha to another would have the same major version >> > number and would therefore not be possible, so maybe we have to use the >> > catalog version number in there. >> >> Good point. Using catversion for the purpose seems a bit ugly but >> I have no better ideas. > > I thought we had rejected the idea of being able to migrate between > alphas. Is migrating between major versions not difficult enough? We like a challenge. ....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 |