Thread: Taking databases offline
Hi! Is it possible (and safe) to move database files to other location while server is working? I had to move one to another volume/path and 'sym-linked' it to old dir. But had to shutdown server first. So my question (and suggestion) is to consider: ALTER DATABASE <dbname> { OFFLINE [ { WAIT | IMMEDIATE }] | ONLINE }; Taking db offline with IMMEDIATE disconnects all sessions, with WAIT option... waits for all sessions to disonnect, with no options - fails if anyone is connected to database; then file system actions are allowed (like in my case). After ALTER... ONLINE normal use of database is restored. Waitng for comments, Mariusz Czulada
"Mariusz Czu�ada" <manieq@idea.net.pl> writes: > Is it possible (and safe) to move database files to other location while > server is working? No. Shut down the postmaster first. > But had to shutdown server first. So my question (and > suggestion) is to consider: > ALTER DATABASE <dbname> { OFFLINE [ { WAIT | IMMEDIATE }] | ONLINE }; Of course, you have this ability now on an installation-wide basis with the available postmaster shutdown options. It's difficult to get excited about expending the work to make this doable on a per-database basis, mainly because I foresee multi-database installations getting much less popular once we implement SQL schemas. Lots of schemas in one (user) database per installation will become the norm, I think. In that scenario a per-database shutdown option will be useless. regards, tom lane
> > But had to shutdown server first. So my question (and > > suggestion) is to consider: > > ALTER DATABASE <dbname> { OFFLINE [ { WAIT | IMMEDIATE }] | ONLINE }; > > Of course, you have this ability now on an installation-wide basis > with the available postmaster shutdown options. It's difficult to get > excited about expending the work to make this doable on a per-database > basis, mainly because I foresee multi-database installations getting > much less popular once we implement SQL schemas. Lots of schemas in > one (user) database per installation will become the norm, I think. > In that scenario a per-database shutdown option will be useless. You can shut database access with pg_hba.conf. I would edit pg_hba.conf, shutdown postmaster to flush all pages, then start up with database inactive. You can then re-enable access to the database later with pg_hba.conf. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026