On Thu, Dec 19, 2013 at 1:18 PM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: > On Thu, Dec 19, 2013 at 01:08:18PM -0800, Sergey Konoplev wrote: >> On Thu, Dec 19, 2013 at 12:49 PM, Joseph Kregloh >> <jkregloh@xxxxxxxxxxxxxx> wrote: >> > On Thu, Dec 19, 2013 at 3:46 PM, Sergey Konoplev <gray.ru@xxxxxxxxx> wrote: >> >> Can you show what ls -l /home/jkregloh/pg_data/data/pg_tblspc/ prints, >> >> please? >> >> >> > [pgsql@postgres-93-upgrade ~]$ ls -l /home/jkregloh/pg_data/data/pg_tblspc/ >> > lrwxr-xr-x 1 pgsql pgsql 41 Dec 19 19:53 11047389 -> >> > /home/jkregloh/pg_data/data/stats_dbspace >> >> Doesn't pg_upgrade do a stright replace of -d dir with -D dir >> everywhere in paths? > > pg_upgrade is looking at the data dir, the database oid, and relfilenode > to get the old path, and does the same for the new path. Tablespaces > point to the same location in old and new clusters --- only a > subdirectory PG_VERISON is different. > > Is /home/jkregloh/pg_data/data also your default cluster directory? If > so, having tablespaces inside of there will not work well as they will > continue to be stored in the old cluster's data directory. Those will > not be renamed/relocated by pg_upgrade. The thing is that /home/jkregloh/pg_data/data is his 9.0's cluster directory and /usr/local/pgsql/data/ is 9.3's one. And pg_upgrade tries to copy /usr/local/pgsql/data/drupal_dbspace/PG_9.0_201008051/2752430/10913518" to /usr/local/pgsql/data/drupal_dbspace/PG_9.3_201306121/16499/12301. In other words pg_upgrade thinks that the old tablespace is located in the same cluster directory as the new one. That made me think that it just replaces the cluster directory subpath everywhere. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray.ru@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
