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/