| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Serguei Mokhov" <sa_mokho(at)alcor(dot)concordia(dot)ca> |
| Cc: | "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Kelly Harmon" <kelly(dot)harmon(at)byers(dot)com> |
| Subject: | Re: Accessing Database files on a "read-only" medium...like a CD. |
| Date: | 2001-10-08 16:12:06 |
| Message-ID: | 1552.1002557526@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Serguei Mokhov" <sa_mokho(at)alcor(dot)concordia(dot)ca> writes:
> Kelly Harmon <kelly(dot)harmon(at)byers(dot)com> wrote in message news:9pr7f7$k0j$1(at)news(dot)tht(dot)net(dot)(dot)(dot)
>> At that point, it seems that your screwed...in that even if you shut down
>> postgres and restart it, somewhere it knows that that database has data that
>> needs to be written to disk, and it refuses to continue until it does so.
> Isn't it the WAL who 'remembers' this info?
Both WAL and pg_log *must* be on writable media, so there's really no
chance of putting the whole of a $PGDATA tree onto a CD. However one
could imagine putting individual databases (or even individual tables)
onto CD. One thing you'd have to watch out for is that Postgres
may try to update on-row commit status bits even during a read-only
operation such as SELECT. The best way to deal with that would be to
VACUUM the table or database before moving it to read-only storage.
VACUUM would leave the status bits all set correctly.
We've talked repeatedly about implementing a notion of tablespaces
to allow DBAs to exercise more control over where tables are kept.
Maybe it'd make sense to allow tablespaces to be marked read-only, too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-10-08 18:43:07 | Re: [patch] ALTER RENAME and indexes |
| Previous Message | Dave Page | 2001-10-08 15:57:16 | Re: Daily snapshots hosed (was Re: [pgadmin-hackers] Wh |