Re: restrict global access to be readonly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, happy times <guangzhouzhang(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "funnyxj(dot)fxj" <funnyxj(dot)fxj(at)alibaba-inc(dot)com>, "dingqi(dot)lxb" <dingqi(dot)lxb(at)taobao(dot)com>
Subject: Re: restrict global access to be readonly
Date: 2015-02-15 00:24:54
Message-ID: 16691.1423959894@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 2/14/15 3:14 PM, Robert Haas wrote:
>> Although I like the idea, it's not clear to me how to implement it.

> Throw an error in AssignTransactionId/GetNewTransactionId?

A whole lot depends on what you choose to mean by "read only". If it
means the same thing as "all transactions are READ ONLY", that would be
useful for some purposes, and it would have the advantage of having a
visible relationship to a long-established feature with the same name.
If you want it to mean "no writes to disk at all", that's something
totally different, and possibly not all that useful (eg, do you really
want to make sorts fail if they'd spill to disk? How about hint bit
updates?). Jim's suggestion above would be somewhere in the middle,
as it would successfully block use of temp tables but not eg. VACUUM.
Another possibility that would be attractive for replication-related
use-cases would be "nothing that generates WAL thank you very much".

I'm inclined to think that we should agree on the desired semantics
before jumping to implementation.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2015-02-15 01:46:55 Allow "snapshot too old" error, to prevent bloat
Previous Message Kevin Grittner 2015-02-15 00:19:45 Reduce pinning in btree indexes