I am trying to create a tablespace in a Windows folder, but nothing seems to be working.
I am doing so with pgadmin.
CREATE TABLESPACE test
LOCATION 'C:\test'
This gives me error:
ERROR: tablespace location must be an absolute path
SQL state: 42P17
I have tried writing the location differently:
'C:/test'
'C:\\test'
'C://test'
But nothing fixes it.
Where is the issue?
Two things to verify, which you have not made clear:
Is your database running on a Windows Server?
Have you actually already created the folder?
Both of theses are necessary in your case. A tablespace is not created so much as it is assigned. The create only creates the Postgres internal definition not the physical implementation. From the Documentation
The location must be an existing, empty directory that is owned by the
PostgreSQL operating system user. All objects subsequently created
within the tablespace will be stored in files underneath this
directory. The location must not be on removable or transient storage,
as the cluster might fail to function if the tablespace is missing or
lost.
Related
We have a PostgreSQL instance running in a VM in the Google Cloud. The nature of the queries that we run involves lots of PostgreSQL temporary table space. (5 or 6 or more TB of disk I/O every day)
This I/O continues to be a major bottleneck in our database. Currently I have it all happening on an SSD persistent disk - not because we need to save any of the data in the event of a reboot, but because PostgreSQL lays out a file structure on the disk that it then uses for the temporary tables and if the file structure is missing when the database starts up, it isn't very good.
What I'd like to do is configure the temporary tablespace on the local SSD's because of their much higher I/O throughput. Unfortunately, they get wiped out on every reboot. I'd like a simple way to be able to re-layout the disk after reboot and before PostgreSQL starts back up.
I could tar up the empty file structure and then write a script that untars it after every boot. Does that make sense? Is there a better way/best practice for doing this?
What would be awesome is if there was a PostgreSQL extension out there that did this magically.
Ideas?
I dug a bit into my previous tests and here is some summary:
PostgreSQL tablespace is just a directory - no big deal. Plus - if you will use it only as temporary table space there will be no persistent file left when you shutdown database.
You can create tablespace for temp tables on any location you want and then go to this location and check directory structure to see what PG created. But you must do under OS because PG will show you only tablespace main directory - both \db+ in psql or select oid, spcname, pg_tablespace_location(oid) from pg_tablespace; work the same way.
My example:
(I used /tempspace/pgtemp as presumed mounting point) CREATE TABLESPACE p_temp OWNER xxxxxx LOCATION '/tempspace/pgtemp'; created in my case structure /tempspace/pgtemp/PG_10_201707211
I set temp_tablespaces = 'pg_temp' in postgresql.conf and reloaded configuration.
When I used create temp table .... PG added another subdirectory - /tempspace/pgtemp/PG_10_201707211/16393 = oid of schema - but this does not matter for temp tablespace because if this subdirectory will be missing PG will create it.
PG created in this subdir files for temp table.
When I closed this session files for temp table were gone.
Now I stopped PG and tested what would happened if directories will be missing:
I deleted PG_10_201707211 with its subdir
started PG and log showed message LOG: could not open tablespace directory "pg_tblspc/166827/PG_10_201707211": No such file or directory but PG started
I tried to create temp table - I got error message ERROR: could not create directory "pg_tblspc/166827/PG_10_201707211/16393": No such file or directory SQL state: 58P01
Now (with running PG) I issued these commands in OS:
sudo mkdir -p /tempspace/pgtemp/PG_10_201707211
sudo chown postgres:postgres -R /tempspace/pgtemp
sudo chmod 700 -R /tempspace/pgtemp
I tried to create temp table again and insert and select values and everything worked OK
So conclusion is - since PG tablespace is no "big magic" just directories you can simply create bash script running on linux startup which will check (and mount if necessary) local SSD and create necessary directories for PG temp tablespace.
When I am restoring the database, by default data is going in C drive, but when I installed the db2 that time I specify the path in D drive only.
Also, sample database files created by db2 is stored in D drive.
Can anyone please tell me what is the issue?
I have run this command:
SELECT * FROM SYSIBMADM.DBPATHS
below is the result i fetched:
LOGPATH- D:\DB2\NODE000\SQL00001\SQLOGDIR\
DB_STORAGE_PATH- C:\
LOCAL_DB_DIRECTORY - D:\DB2\NODE000\SQLOGDIR\
DBPATH - D:\DB2\NODE000\SQL00001\
I Want to change this DB_STORAGE_PATH C:\ to D:\ for all the database which i will be restoring.
You can run db2set from db2 command line that will confirm you wheather db2 installed on path with other information;
db2-command-line> db2set
DB2_ATS_ENABLE=YES
DB2_CREATE_DB_ON_PATH=YES
DB2INSTPROF=C:\where\db2\installed\IBM\DB2\DB2COPY1
DB2COMM=TCPIP
You can get more information of Directory structure for your installed DB2 database product (Windows) here
You can run the following command SELECT * FROM SYSIBMADM.DBPATHS. This will give details of following variables of your installed db2 database;
LOGPATH
DB_STORAGE_PATH
LOCAL_DB_DIRECTORY
DBPATH
These commands will provide you enough information to locate your installed database. Then you can restore your database providing the exact path.
To add a storage path to an existing database, issue the following ALTER DATABASE statement:
ALTER DATABASE database-name ADD STORAGE ON storage-path
After adding one or more storage paths to the database, you may use the ALTER TABLESPACE statement to rebalance table spaces in the database so that they start to use the new storage paths immediately.
DB2 has a configuration parameter for the default path for databases, dftdbpath. In addition, the command db2sampl to create a sample database has an option dbpath to specify where to place that database.
db2sample -dbpath D:
The above would place the new database on drive D:.
You will find that there are default paths for certain operations. The overview of DB2 database manager configuration parameters has lists most of them.
For your specific issue I would assume that a parameter was changed some time after DB2 was installed and used initially.
For RESTORE be aware that the options TO and DBPATH are ignored if restoring an existing database.
I am currently moving some data around and I am running into an interesting issue.
I have a CentOS server (6.3) up and running with Postgres 9.2 on a server with limited built in disk space; however, I do have a large amount of extremely reliable external network disk space available.
I have set the tablespace to a directory on this storage devise for my database and everything seems to be working well, until...
I realized that I have a large amount of BLOB data that needs to be stored in pg_largeobject.
I have been goggling how to set the tablespace of pg_largeobject and I did find some results, but they are horribly out dated.
I did find one article that looks promising, but I'm hesitant because the thread also references that things will/should have changed.
I have two questions...
In an ideal world, I would like to move all of postgres (including pg_largeobject) onto this external storage for ease of maintenance. Is this possible?
If not, how can I get pg_largeobject to use my network storage?
As you alluded to, your best bet is to move the entirety of PostgreSQL onto the remote storage, assuming that storage uses a reliable file network block device like iSCSI, ATAoE or NBD. I wouldn't recommend running Pg on NFS, and running it on CIFS/SMBFS just won't work.
Just:
Make a backup
Take a note of the output of SHOW data_directory; in psql
Shut PostgreSQL down
Move the data directory (the folder containing pg_xlog, pg_clog, etc) to the remote storage
Adjust the permissions on the parent directories for the datadir's new location to make sure the postgres user, postgres, group or others permissions block has at least execute on each parent directory so it can traverse the tree.
Adjust your system startup scripts to set the new location as the PostgreSQL datadir or symlink the old datadir location (output by SHOW data_directory) to the new location.
Start PostgreSQL
Unfortunately, different systems and packages find the datadir different ways. Debian/Ubuntu use pg_wrapper, for example.
i would like to be able to do something like
CREATE TABLESPACE bob location 'C:\a\b\c\d\e\f\bob'
without needing to create all the directory tree beforehand.
this is because i have java code that creates tablespaces on the fly and i would like to be able to run it on a separate machine (so it couldnt mkdir() or anything).
is there any sort of postgres configuration that would allow me to make postgres create the appropriate directory tree by itself?
You could try do mkdir directly in postgres stored procedure using PL/sh or any of your favorite PL/* languages that are available for PostgreSQL
I'm trying to create a tablespace in postgres, but I'm getting ownership problems. The command I'm using is:
CREATE TABLESPACE magdat OWNER maggie LOCATION '/home/john/BSTablespace'
I get the error:
ERROR: could not set permissions on directory "/home/john/BSTablespace": Operation not permitted
The folder belongs to postgres:postgres, I've tried changing it to maggie, but if I go :
chown maggie:postgres /home/john/BSTablespace
I get:
chown: invalid user: `maggie:postgres'
How come the user does not exist? If I list the users inside of postgres it does come up. Any ideas what I could be doing wrong?
I would hazard a guess that the problem lies in the permissions of the parent directory "/home/john". Your home directory is probably setup so that only your user has access (i.e chmod 700) to it (it's a good thing for your home directory to be chmod 700, don't change it).
Doing something like:
mkdir /BSTablespace
chown postgres:postgres /BSTablespace
and then
CREATE TABLESPACE magdat OWNER maggie LOCATION '/BSTablespace';
should work fine.
Regarding the user maggie: database users are not the same as OS users. That isn't to say that you couldn't have a user in both places named maggie-- but you would need to create the user in both the database and the OS for that to happen.
When you install Postgres on a Mac, and are trying to use PgAdmin to create your databases, tablespaces, etc. You need to know that the PgAdmin Utility is running under the postgres account that it created when you installed the postgres database and the utilities.
The postgres account is part of the _postgres group
( dscacheutil -q group|grep -i postgres command will list the group associated with the postgres account)
The best practice would be to create a new directory under root(/) for housing the tablespaces,(let us call it /postgresdata then make postgres:_postgres the owners of that directory, using the command below)
sudo chown postgres:_postgres /postgresdata
This should do it for you.
You could then create a subdirectory under /postgresdata for each unique table space
There is a problem with this solution. Think about it. Why do you want to create a new tablespace? Most people do it for either space limitations or performance. In both cases, that means placing each tablespace on a different drive. So, archive data goes on the slower hard-drive, while actively used data does on the SSD.
Assume your OS is on the SSD and you have mounted your slower spin up hard drive as /media/slowdrive. The same dilemma would occur if the reverse, where the spinup is the OS and SSD is the mounted.
Your solution would place the new tablespace at /newtablespace.
Do you see the problem? ... /newtablespace is on the SSD, which does not have the capacity to hold both the archival and active data. If it did, we would not be creating a new tablespace in the first place.
So, how do we solve this issue when our newtablespace is mounted at /media/slowdrive/newtablespace? In my case, the slowdrive (spinup HD) is mounted as root:root for security purposes, although I am not entirely sure about why. What you are suggesting is that I have to chage the mount of my secondary drive to postgres:postgres in addition to having the newtablespace directory as postgres:postgres. That makes no sense, especially since I use this drive for many other reasons than just a postgres tablesapce.
Joe