Re: read-only database - Mailing list pgsql-hackers

From Tom Lane
Subject Re: read-only database
Date
Msg-id 6091.1110986666@sss.pgh.pa.us
Whole thread Raw
In response to read-only database  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Responses Re: read-only database  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Re: read-only database  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
List pgsql-hackers
Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
>> * Allow a warm standby system to also allow read-only queries

> Does anyone have any plan to work on this?

> I think we need to extend the pg_database catalog to
> have a database state (read-only or writable),
> and also need to extend ALTER DATABASE command
> to change the state.

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.  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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Erratic error message "ERROR: column "id_compte" does
Next
From: Tom Lane
Date:
Subject: Re: PQexecParams