Обсуждение: Taking databases offline

Поиск
Список
Период
Сортировка

Taking databases offline

От
"Mariusz Czu³ada"
Дата:
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




Re: Taking databases offline

От
Tom Lane
Дата:
"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


Re: Taking databases offline

От
Bruce Momjian
Дата:
> > 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