New tablespace: just an advice - Mailing list pgsql-general

From Moreno Andreo
Subject New tablespace: just an advice
Date
Msg-id cfb7a3f5-2cf6-59a5-2fd2-5b27b3b4bae1@evolu-s.it
Whole thread Raw
Responses Re: New tablespace: just an advice  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
Hi everyone!

My space on my Debian 8 DB server is running a bit low (10% left of a 
2TB disk), so, since it's not possible to have a primary MBR disk with 
size > 2 TB, I decided to create another disk and map it on the server, 
creating another tablespace on it and moving databases aross disks to 
balance disk usage.

After creating a test server on this night's production server image, I 
created a folder and assigned ownership to postgres user
mkdir /newdisk/tbsp_new
chown -R postgres /newdisk/tbsp_new

then created new tablespace
create tablspace tb2 location '/newdisk/tbsp_new';

and moved a database
alter database db set tablespace tb2;

As you can see a flat, basic tablespace with no customizations.
I just ran a VACUUM FULL on the cluster before creating tablespace.
After the ALTER DATABASE command ran successful, I checked disk space 
(df -h) and saw some more free space on primary disk, and the same space 
occupied on new disk. Just what I needed.
I psql'd in the cluster with the user's username connecting on the 
database just migrated, and was able to SELECT and UPDATE (not tried 
INSERTing).

Now, 2 questions.
1. Is it all or do I need to adjust something else about permissions, 
indexes, vacuuming, etc...?
ALTERing the database namespace means copying its physical files to new 
directory, but is it applied to all objects (indexes, triggers, etc)?

2. What will happen to who tries to access the database while it's being 
moved from one tablespace to another?

Thanks in advance,
Moreno.



pgsql-general by date:

Previous
From: Shrikant Bhende
Date:
Subject: FATAL: terminating connection because protocol synchronization was lost
Next
From: Adrian Klaver
Date:
Subject: Re: Enabling autovacuum per table