Re: read-only database
От | Satoshi Nagayasu |
---|---|
Тема | Re: read-only database |
Дата | |
Msg-id | 4238D14D.6020205@nttdata.co.jp обсуждение исходный текст |
Ответ на | Re: read-only database (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: read-only database
|
Список | pgsql-hackers |
Tom Lane wrote: > Uh, no, because changing that would by definition not be a read-only > operation. Therefore there'd be no way to enter the read-only state, > and definitely no way to get out of it again. I saw Oracle's reference manual, and found ALTER DATABASE OPEN READ ONLY command to make a stand-by database. In Oracle, when the user execute the command, the database goes read-only mode. Is this a bad idea? I guess some users need per-database read-only state. Don't we need to have both read-only and writable databases in single cluster? Of course, the super-user can change the database state even in read-only. > Furthermore, the > envisioned behavior is cluster-wide not per-database: the point is > to not execute transactions and not generate WAL entries, and you > don't get to be selective about that. (If it doesn't work like that, > you couldn't use it for the intended purpose of examining the state > of a hot-standby PITR backup that is actively tracking WAL logs > shipped from a master. It'd also not be useful for looking at > a corrupted cluster.) > > I'd view this as a postmaster state that propagates to backends. > Probably you'd enable it by means of a postmaster option, and the > only way to get out of it is to shut down and restart the postmaster > without the option. I agree this is a reasonable way to make cluster-wide read-only state. -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp> OpenSource Development Center, NTT DATA Corp. http://www.nttdata.co.jp/
В списке pgsql-hackers по дате отправления: