Thread: Running pg_upgrade under Debian
Hello, I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this error:- postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin -d /home/postgres/data93/userqueries -D /home/postgres/data94/userqueries -U pguserqueries check for "/home/postgres/data93/userqueries/base" failed: No such file or directory Failure, exiting postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade --version pg_upgrade (PostgreSQL) 9.4.1 I have two tablespaces defined for this data -- one to hold the tables and another for the indices. There is no "base" file or directory. Do I just create a dummy directory named "base"? If there is supposed to be a directory or file named "base" why wasn't it created by initdb? Regards, Robert
On Sat, Apr 18, 2015 at 08:09:43AM +1000, rob stone wrote:
> I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this
> error:-
>
>
> postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade
> -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin
> -d /home/postgres/data93/userqueries
> -D /home/postgres/data94/userqueries -U pguserqueries
For what it's worth: Debian provides a
pg_upgradecluster
tailored to its specific setup of PostgreSQL clusters. That
has worked well for me across several major version bumps.
Karsten
> check for "/home/postgres/data93/userqueries/base" failed: No such file
> or directory
>
> Failure, exiting
> postgres@roblaptop:/usr/lib/postgresql/9.4/bin$
>
> postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade --version
> pg_upgrade (PostgreSQL) 9.4.1
>
>
> I have two tablespaces defined for this data -- one to hold the tables
> and another for the indices.
>
> There is no "base" file or directory.
>
> Do I just create a dummy directory named "base"?
>
> If there is supposed to be a directory or file named "base" why wasn't
> it created by initdb?
>
>
> Regards,
> Robert
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On Sat, 2015-04-18 at 00:25 +0200, Karsten Hilbert wrote: > On Sat, Apr 18, 2015 at 08:09:43AM +1000, rob stone wrote: > > > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this > > error:- > > > > > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade > > -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin > > -d /home/postgres/data93/userqueries > > -D /home/postgres/data94/userqueries -U pguserqueries > > For what it's worth: Debian provides a > > pg_upgradecluster > > tailored to its specific setup of PostgreSQL clusters. That > has worked well for me across several major version bumps. > > Karsten > Indeed I have that program installed in /usr/lib but the man pages state that it cannot handle tablespaces. So, I guess I have to move to Plan B, use pg_dump from the old version and then import into 9.4.1. Thanks for your help. Robert > > check for "/home/postgres/data93/userqueries/base" failed: No such file > > or directory > > > > Failure, exiting > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ > > > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade --version > > pg_upgrade (PostgreSQL) 9.4.1 > > > > > > I have two tablespaces defined for this data -- one to hold the tables > > and another for the indices. > > > > There is no "base" file or directory. > > > > Do I just create a dummy directory named "base"? > > > > If there is supposed to be a directory or file named "base" why wasn't > > it created by initdb? > > > > > > Regards, > > Robert > > > > > > > > -- > > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-general > > -- > GPG key ID E4071346 @ eu.pool.sks-keyservers.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 > >
On 04/17/2015 03:09 PM, rob stone wrote: > Hello, > > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this > error:- > > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade > -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin > -d /home/postgres/data93/userqueries > -D /home/postgres/data94/userqueries -U pguserqueries > > check for "/home/postgres/data93/userqueries/base" failed: No such file > or directory > > Failure, exiting > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade --version > pg_upgrade (PostgreSQL) 9.4.1 > > > I have two tablespaces defined for this data -- one to hold the tables > and another for the indices. > > There is no "base" file or directory. Guessing /home/postgres/data*/userqueries/ is the location of your tablespace, not the cluster directory. The -d and -D need to point at the cluster directory, which will be something like : /var/lib/postgresql/9.3/main > > Do I just create a dummy directory named "base"? No, you need to point to the correct directory. See here for more information: http://www.postgresql.org/docs/9.4/interactive/pgupgrade.html Or use pg_upgradecluster: http://manpages.ubuntu.com/manpages/trusty/man8/pg_upgradecluster.8.html > > If there is supposed to be a directory or file named "base" why wasn't > it created by initdb? > > > Regards, > Robert > > > -- Adrian Klaver adrian.klaver@aklaver.com
On Fri, 2015-04-17 at 16:16 -0700, Adrian Klaver wrote: > On 04/17/2015 03:09 PM, rob stone wrote: > > Hello, > > > > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this > > error:- > > > > > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade > > -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin > > -d /home/postgres/data93/userqueries > > -D /home/postgres/data94/userqueries -U pguserqueries > > > > check for "/home/postgres/data93/userqueries/base" failed: No such file > > or directory > > > > Failure, exiting > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ > > > > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade --version > > pg_upgrade (PostgreSQL) 9.4.1 > > > > > > I have two tablespaces defined for this data -- one to hold the tables > > and another for the indices. > > > > There is no "base" file or directory. > > Guessing /home/postgres/data*/userqueries/ is the location of your > tablespace, not the cluster directory. > Correct. > The -d and -D need to point at the cluster directory, which will be > something like : > > /var/lib/postgresql/9.3/main > > > > > Do I just create a dummy directory named "base"? > > No, you need to point to the correct directory. > > See here for more information: > > http://www.postgresql.org/docs/9.4/interactive/pgupgrade.html > Actually, the wiki pages on upgrading gave me some more information, particularly about specifying where to find postgresql.conf. I adopted the symlink suggestion. However, running the following still gives errors:- postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade -b /usr/lib/postgresql/9.3/bin -B /usr/lib/postgresql/9.4/bin -d /var/lib/postgresql/9.3/main -D /var/lib/postgresql/9.4/main -p 5432 -P 5433 -o ' -c listen_addresses=localhost ' -O ' -c listen_addresses=localhost ' --check --verbose Running in verbose mode Performing Consistency Checks ----------------------------- Checking cluster versions ok pg_control values: First log segment after reset: 000000010000000000000002 pg_control version number: 937 Catalog version number: 201306121 Database system identifier: 6026352641161422830 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/684 Latest checkpoint's NextOID: 12036 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Latest checkpoint's oldestXID: 674 Latest checkpoint's oldestXID's DB: 1 Latest checkpoint's oldestActiveXID: 0 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value Data page checksum version: 0 Current pg_control values: pg_control version number: 942 Catalog version number: 201409291 Database system identifier: 6108663141646003887 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/719 Latest checkpoint's NextOID: 12142 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Latest checkpoint's oldestXID: 675 Latest checkpoint's oldestXID's DB: 1 Latest checkpoint's oldestActiveXID: 0 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Size of a large-object chunk: 2048 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value Data page checksum version: 0 Values to be changed: First log segment after reset: 000000010000000000000002 "/usr/lib/postgresql/9.3/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/9.3/main" -o "-p 5432 -b -c listen_addresses=localhost -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/usr/lib/postgresql/9.4/bin'" start >> "pg_upgrade_server.log" 2>&1 *failure* There were problems executing ""/usr/lib/postgresql/9.3/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/9.3/main" -o "-p 5432 -b -c listen_addresses=localhost -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/usr/lib/postgresql/9.4/bin'" start >> "pg_upgrade_server.log" 2>&1" Consult the last few lines of "pg_upgrade_server.log" for the probable cause of the failure. pg_ctl failed to start the old server, or connection failed Failure, exiting postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ---- The last few lines of pg_upgrade_server.log show:- ----------------------------------------------------------------- pg_upgrade run on Mon Apr 20 01:36:44 2015 ----------------------------------------------------------------- command: "/usr/lib/postgresql/9.3/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/9.3/main" -o "-p 5432 -b -c listen_addresses=localhost -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/usr/lib/postgresql/9.4/bin'" start >> "pg_upgrade_server.log" 2>&1 waiting for server to start....2596 5533cb8c.a24 2015-04-20 01:36:44 AESTLOG: redirecting log output to logging collector process 2596 5533cb8c.a24 2015-04-20 01:36:44 AESTHINT: Future log output will appear in directory "pg_log". .... stopped waiting pg_ctl: could not start server Examine the log output. ------ So, on the command line I'm putting "listen_addresses=localhost" which pg_upgrade picks up but the following option sets this to ''. It is starting pg_ctl in the 9.3/bin directory but makes the socket directory in 9.4/bin?? If pg_upgrade is actually reading the conf files it should not be necessary to supply any of these options, as port numbers, PID file locations, etc. are specified there. I'm really confused. I don't believe that my set-up is so weird that pg_upgrade won't work out of the box. Obviously I'm doing something that is wrong. Cheers, Robert
On Sun, Apr 19, 2015 at 9:34 AM, rob stone <floriparob@gmail.com> wrote:
On Fri, 2015-04-17 at 16:16 -0700, Adrian Klaver wrote:
> On 04/17/2015 03:09 PM, rob stone wrote:
> > Hello,
> >
> > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this
> > error:-
> >
> >
> > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade
...
So, on the command line I'm putting "listen_addresses=localhost" which
pg_upgrade picks up but the following option sets this to ''.
It is starting pg_ctl in the 9.3/bin directory but makes the socket
directory in 9.4/bin??
Note that 9.4/bin seems to be the current working directory from which you are running the command. That is probably not such a good idea.
If pg_upgrade is actually reading the conf files it should not be
necessary to supply any of these options, as port numbers, PID file
locations, etc. are specified there.
If pg_upgrade used the values from the config files, then anyone who is accustomed to connecting to the database with those setting could unthinkingly connect to it during the upgrade process and screw up the upgrade. It intentionally chooses methods to prevent that from happening, by putting the socket somewhere private, or at least unpredictable.
waiting for server to start....2596 5533cb8c.a24 2015-04-20 01:36:44
AESTLOG: redirecting log output to logging collector process
2596 5533cb8c.a24 2015-04-20 01:36:44 AESTHINT: Future log output will
appear in directory "pg_log"
However, it appears appear that pg_upgrade does honor the logging-collector related settings from the config file (should it? I can see arguments both ways) and you so you have to look in the pg_log directory to figure out what the actual problem is.
Cheers,
Jeff
On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote: > > For what it's worth: Debian provides a > > > > pg_upgradecluster > > > > tailored to its specific setup of PostgreSQL clusters. That > > has worked well for me across several major version bumps. > > > > Karsten > > > > Indeed I have that program installed in /usr/lib but the man pages state > that it cannot handle tablespaces. Wow, that is odd. I wonder why. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 04/20/2015 12:49 PM, Bruce Momjian wrote: > On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote: >>> For what it's worth: Debian provides a >>> >>> pg_upgradecluster >>> >>> tailored to its specific setup of PostgreSQL clusters. That >>> has worked well for me across several major version bumps. >>> >>> Karsten >>> >> >> Indeed I have that program installed in /usr/lib but the man pages state >> that it cannot handle tablespaces. > > Wow, that is odd. I wonder why. > Best guess is because pg_upgradecluster is a wrapper script that by default uses pg_dump/pg_restore. Using is pg_upgrade is the second choice. http://manpages.ubuntu.com/manpages/trusty/man8/pg_upgradecluster.8.html -- Adrian Klaver adrian.klaver@aklaver.comp
On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote: > On 04/20/2015 12:49 PM, Bruce Momjian wrote: > >On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote: > >>>For what it's worth: Debian provides a > >>> > >>> pg_upgradecluster > >>> > >>>tailored to its specific setup of PostgreSQL clusters. That > >>>has worked well for me across several major version bumps. > >>> > >>>Karsten > >>> > >> > >>Indeed I have that program installed in /usr/lib but the man pages state > >>that it cannot handle tablespaces. > > > >Wow, that is odd. I wonder why. > > > Best guess is because pg_upgradecluster is a wrapper script that by > default uses pg_dump/pg_restore. Using is pg_upgrade is the second > choice. > > http://manpages.ubuntu.com/manpages/trusty/man8/pg_upgradecluster.8.html But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do as well. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 04/20/2015 02:42 PM, Bruce Momjian wrote: > On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote: >> On 04/20/2015 12:49 PM, Bruce Momjian wrote: >>> On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote: >>>>> For what it's worth: Debian provides a >>>>> >>>>> pg_upgradecluster >>>>> >>>>> tailored to its specific setup of PostgreSQL clusters. That >>>>> has worked well for me across several major version bumps. >>>>> >>>>> Karsten >>>>> >>>> >>>> Indeed I have that program installed in /usr/lib but the man pages state >>>> that it cannot handle tablespaces. >>> >>> Wow, that is odd. I wonder why. >>> >> Best guess is because pg_upgradecluster is a wrapper script that by >> default uses pg_dump/pg_restore. Using is pg_upgrade is the second >> choice. >> >> http://manpages.ubuntu.com/manpages/trusty/man8/pg_upgradecluster.8.html > > But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do > as well. > I don't think it is about the underlying programs, it is about teaching the wrapper script what do with the choices. Sort of like pgAdmin not supporting all pg_backup/pg_restore combinations or for that matter pg_restore not knowing what to do with a plain text pg_dump file. -- Adrian Klaver adrian.klaver@aklaver.com
On Mon, Apr 20, 2015 at 03:02:48PM -0700, Adrian Klaver wrote: > >But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do > >as well. > > > > I don't think it is about the underlying programs, it is about > teaching the wrapper script what do with the choices. Sort of like > pgAdmin not supporting all pg_backup/pg_restore combinations or for > that matter pg_restore not knowing what to do with a plain text > pg_dump file. Understoo, but I was not aware there was anything special required for pg_upgrade to support tablespaces. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
ISTM there's a documentation bug here: in the code, the "dump" method checks for tablespaces and raises an error if they are found, but the "upgrade" method does not check. I think the documentation should state that only the dump method does not support tablespaces. Bruce Momjian wrote: > On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote: > > On 04/20/2015 12:49 PM, Bruce Momjian wrote: > > >On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote: > > >>>For what it's worth: Debian provides a > > >>> > > >>> pg_upgradecluster > > >>> > > >>>tailored to its specific setup of PostgreSQL clusters. That > > >>>has worked well for me across several major version bumps. > > >>> > > >>>Karsten > > >>> > > >> > > >>Indeed I have that program installed in /usr/lib but the man pages state > > >>that it cannot handle tablespaces. > > > > > >Wow, that is odd. I wonder why. > > > > > Best guess is because pg_upgradecluster is a wrapper script that by > > default uses pg_dump/pg_restore. Using is pg_upgrade is the second > > choice. > > > > http://manpages.ubuntu.com/manpages/trusty/man8/pg_upgradecluster.8.html > > But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do > as well. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: > ISTM there's a documentation bug here: in the code, the "dump" method > checks for tablespaces and raises an error if they are found, but the > "upgrade" method does not check. I think the documentation should state > that only the dump method does not support tablespaces. OK, it would be nice if someone could report that to upstream Debian. I am a little confused why pg_dump/pg_restore can't use tablespaces though. Years ago we used to not use PG-major-version-specific subdirectories in tablespaces, but we added that for pg_upgrade, and I am sure they would work fine for pg_dump too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Bruce Momjian wrote: > On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: > > ISTM there's a documentation bug here: in the code, the "dump" method > > checks for tablespaces and raises an error if they are found, but the > > "upgrade" method does not check. I think the documentation should state > > that only the dump method does not support tablespaces. > > OK, it would be nice if someone could report that to upstream Debian. That's why I added myon@debian.org to the CC list. > I am a little confused why pg_dump/pg_restore can't use tablespaces > though. Years ago we used to not use PG-major-version-specific > subdirectories in tablespaces, but we added that for pg_upgrade, and I > am sure they would work fine for pg_dump too. Maybe they haven't gotten the memo yet. This was implemented in 9.0, and as I recall Debian supported 8.4 until recently. Perhaps they just need to remove the check now. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 04/20/2015 03:18 PM, Alvaro Herrera wrote: > Bruce Momjian wrote: >> On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: >>> ISTM there's a documentation bug here: in the code, the "dump" method >>> checks for tablespaces and raises an error if they are found, but the >>> "upgrade" method does not check. I think the documentation should state >>> that only the dump method does not support tablespaces. >> >> OK, it would be nice if someone could report that to upstream Debian. > > That's why I added myon@debian.org to the CC list. > >> I am a little confused why pg_dump/pg_restore can't use tablespaces >> though. Years ago we used to not use PG-major-version-specific >> subdirectories in tablespaces, but we added that for pg_upgrade, and I >> am sure they would work fine for pg_dump too. > > Maybe they haven't gotten the memo yet. This was implemented in 9.0, > and as I recall Debian supported 8.4 until recently. Perhaps they just > need to remove the check now. > Well in the code I see a checks for >= 8.2 stepping up to 9.4, so I not sure they could just remove it. -- Adrian Klaver adrian.klaver@aklaver.com
On Mon, 2015-04-20 at 18:05 -0400, Bruce Momjian wrote: > On Mon, Apr 20, 2015 at 03:02:48PM -0700, Adrian Klaver wrote: > > >But pg_upgrade supports tablespaces, and I assume pg_dump/pg_restore do > > >as well. > > > > > > > I don't think it is about the underlying programs, it is about > > teaching the wrapper script what do with the choices. Sort of like > > pgAdmin not supporting all pg_backup/pg_restore combinations or for > > that matter pg_restore not knowing what to do with a plain text > > pg_dump file. > > Understoo, but I was not aware there was anything special required for > pg_upgrade to support tablespaces. > pg_dump will handle tablespaces when you create a sql style dump file. However, you have to alter one line where it sets default_tablespace to null. Obviously, when you run psql to read the dump file the tablespaces have to exist. There is no create statement as it won't know where you want to mount your tablespaces. I've used my Plan "B". Ran pg_dump out of the 9.3 instance, altered that one line, stopped 9.3, started 9.4, ran psql as the postgres user, created the user and tablespaces and imported the dump file. It all worked as intended. So, I now have one of my test databases running under 9.4. Cheers, Robert
On 4/20/15 6:09 PM, Bruce Momjian wrote: > On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: >> ISTM there's a documentation bug here: in the code, the "dump" method >> checks for tablespaces and raises an error if they are found, but the >> "upgrade" method does not check. I think the documentation should state >> that only the dump method does not support tablespaces. > > OK, it would be nice if someone could report that to upstream Debian. I > am a little confused why pg_dump/pg_restore can't use tablespaces > though. Years ago we used to not use PG-major-version-specific > subdirectories in tablespaces, but we added that for pg_upgrade, and I > am sure they would work fine for pg_dump too. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772202
Re: Peter Eisentraut 2015-04-24 <553A3B85.1070609@gmx.net> > On 4/20/15 6:09 PM, Bruce Momjian wrote: > > On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: > >> ISTM there's a documentation bug here: in the code, the "dump" method > >> checks for tablespaces and raises an error if they are found, but the > >> "upgrade" method does not check. I think the documentation should state > >> that only the dump method does not support tablespaces. > > > > OK, it would be nice if someone could report that to upstream Debian. I > > am a little confused why pg_dump/pg_restore can't use tablespaces > > though. Years ago we used to not use PG-major-version-specific > > subdirectories in tablespaces, but we added that for pg_upgrade, and I > > am sure they would work fine for pg_dump too. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772202 Yeah I know, it's on the extended TODO list... Christoph -- cb@df7cb.de | http://www.df7cb.de/