Re: [GENERAL] pg_upgrade & tablespaces
От | Magnus Hagander |
---|---|
Тема | Re: [GENERAL] pg_upgrade & tablespaces |
Дата | |
Msg-id | CABUevEwJpdmfLteao2o9De1A+PS=Ax8D2rnJyBE63ADmUpT=Ag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_upgrade & tablespaces (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Sun, Jan 12, 2014 at 5:26 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Sat, Jan 11, 2014 at 12:48:51PM -0800, Adrian Klaver wrote:Uh, good question. I think I used the system tables because they were
> >pg_upgrade looks in the pg_tablespace in pre-9.2, and uses a function in
> >9.2+. The query is:
> >
> > snprintf(query, sizeof(query),
> > "SELECT %s "
> > "FROM pg_catalog.pg_tablespace "
> > "WHERE spcname != 'pg_default' AND "
> > " spcname != 'pg_global'",
> > /* 9.2 removed the spclocation column */
> > (GET_MAJOR_VERSION(old_cluster.major_version) <= 901) ?
> >--> "spclocation" : "pg_catalog.pg_tablespace_location(oid) AS spclocation");
>
>
> I see, though I have another question. If pg_tablespace and the
> symlinks can get out of sync, as you say below, why is pg_tablespace
> considered the authority? Or to put it another way, why not just
> look at the symlinks as in 9.2+?
easier to access. I can't remember if we used the symlinks for some
things and pg_tablespace for other things in pre-9.2.
If you mean PostgreSQL internally then no, we didn't use pg_tablespace for anything ever. We only used the symlinks. Which is why it was so easy to remove.
If you were using it for something inside pg_upgrade I don't know, but the backend didn't.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: