Josh Berkus wrote:
Well, it eliminates transaction isolation. Completely.
If the data is read-only, you presumably don't need that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: Have you checked
Heikki Linnakangas wrote:
I've been thinking about running postgres from read-only media. It's
handy for creating demo CDs etc.
I think that a read-only installation of PostgreSQL would be a very poor
demonstration of its capabilities. Better put the data in a RAM disk.
--
Peter Eisentraut
On Mon, 21 Nov 2005, Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I've been thinking about running postgres from read-only media. It's
handy for creating demo CDs etc.
I think that a read-only installation of PostgreSQL would be a very poor
demonstration of its capabilities. Better put
On Sun, 20 Nov 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
5. Don't try to write buffers with commit hint modifications. Just discard
them.
The performance costs of that alone are astonishing (ie, repeated
verifications of commit status).
You'd vacuum first to avoid
Heikki Linnakangas wrote:
I think that a read-only installation of PostgreSQL would be a very
poor demonstration of its capabilities. Better put the data in a
RAM disk.
RAM space is limited.
Nowadays, CD space is often more limited than RAM. You could of course
now talk about a DVD
Heikki Linnakangas [EMAIL PROTECTED] writes:
There's also this TODO:
Allow a warm standby system to also allow read-only queries [pitr]
In fact, I was originally thinking of that. I should've mentioned it.
It has the same issues with transactions and WAL as running from
read-only media, so
Hi,
I've been thinking about running postgres from read-only media. It's
handy for creating demo CDs etc. I hacked together a patch that allows
you to run Postgres without write permissions to the data directory.
Some changes are needed:
1. Force all transactions to be read-only, using the
Heikki Linnakangas [EMAIL PROTECTED] writes:
5. Don't try to write buffers with commit hint modifications. Just discard
them.
The performance costs of that alone are astonishing (ie, repeated
verifications of commit status).
I think what you are doing is a completely wrongheaded way to
Heikki,
4. Don't increment xid counter, just use a single xid for all
transactions. Otherwise we might reach the xid wrap-around point, and we
can't vacuum. It seems safe to me, am I missing anything?
Well, it eliminates transaction isolation. Completely.
--
Josh Berkus
Aglio Database
