Greg Stark <gsst...@mit.edu> writes: > On Wed, Dec 2, 2009 at 11:26 AM, Dimitri Fontaine > <dfonta...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers