Greg Stark <gsstark@mit.edu> writes:
> On Wed, Dec 2, 2009 at 11:26 AM, Dimitri Fontaine
> <dfontaine@hi-media.com> wrote:
>> We already have had demand for read only tables (some on-disk format
>> optimisation would then be possible). What about having page level
>> read-only restriction, thus allowing the newer server version to operate
>> in read-only mode on the older server version pages, and convert on
>> write by allocating whole new page(s)?
>
> I'm a bit confused. Read-only tables are tables that the user has said
> they don't intend to modify. We can throw an error if they try. What
> you're proposing are pages that the system treats as read-only but
> what do you propose to do if the user actually does try to update or
> delete (or lock) a record in those pages?
Well it's still a pretty rough idea, so I'll need help from this forum
to get to something concrete enough for someone to be able to implement
it... and there you go:
> If we want to avoid
> converting them to new pages we need to be able to at least store an
> xmax and set the ctid on those tuples. And probably we would need to
> do other things like set hint bits or set fields in the page header.
My idea was more that any non read-only access to the page forces a
rewrite in the new format, and a deprecation of the ancient page. Maybe
like what vacuum would be doing on it as soon as it realises the page
contains no visible tuples anymore, but done by the backend at the time
of the modification.
That makes the first modifications of the page quite costly but allow to
somewhat choose when that happens. And still have read only access, so
you could test parts of your application on a hot standby running next
version.
Maybe there's just too much craziness in there now.
--
dim