I think the read-only has two meanings for the user.
First is the internal state. XID, OID or something like that.
In these cases, the internal state mustn't be changed.
Some users will need the read-only for internal state.
Second is read-only for the user data contents.
In some cases, the user want to make the user data as read-only.
For this purpose, the user doesn't care XID or OID, I guess.
So, we can implement them in different way.
I think both are necessary.
Bruce Momjian wrote:
> Tom Lane wrote:
>
>>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>
>>>It seems server_read_only is the same as default_transaction_read_only
>>>except it can't be changed.
>>
>>I thought the TODO item was for a low-level read-only option, suitable
>>for trying to look at a corrupted database or run off a read-only volume.
>>This is very far from being that --- it allows temp table creation/use,
>>and it still eats transaction IDs so it is certainly not read-only to
>>xlog or clog.
>>
>>I am not sure I see any use case for this implementation: it is
>>read-only enough to get in your way, without being read-only enough
>>to derive any real benefit.
>
>
> I am not sure I see the use case either but I developed it so everyone
> could look at it and decide if it is useful. When true, it is basically
> a unchangable default_transaction_read_only.
>
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
OpenSource Development Center,
NTT DATA Corp. http://www.nttdata.co.jp/
