From: | Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Readonly backend option |
Date: | 2001-05-02 14:12:58 |
Message-ID: | Pine.LNX.4.33.0105021512250.3121-100000@sphinx.mythic-beasts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
[ resent, because I didn't see it appear yesterday ]
Probably a fairly simple question:
For various reasons, I'd like to implement a readonly
backend option. I've been poking around the backend
code, and am slowly getting a feel for it, but I'm far
from sure of the best way to implement such an option.
There are basically two parts that I'd like to hack:
1. To block insert/update/delete/create/alter/drop
queries with a helpful message.
2. The ability to open the datafiles read-only (WAL
included) so that they can be held on a read-only
filesystem.
The latter should be doable, but will require some
effort and testing to catch everything. But where in
the backend should be checks for the former go? I
guess that the executor might be a better place than
the parser, but should I go even lower? There seemed
no obvious way for ExecAppend (for example) to return
failure. Do I just do an elog(NOTICE) and ignore the
query?
I would also like for a readonly backend to be able
safely to coexist with a writable one. Might this be
possible, or are there cases where a backend executing
a readonly transaction needs write something?
Matthew.
From | Date | Subject | |
---|---|---|---|
Next Message | Otto A. Hirr, Jr. | 2001-05-02 14:32:18 | CVSUP - Problems? |
Previous Message | Olivier PRENANT | 2001-05-02 11:51:21 | change database owner |