Re: Accessing Database files on a "read-only" medium...like a CD.
От | Tom Lane |
---|---|
Тема | Re: Accessing Database files on a "read-only" medium...like a CD. |
Дата | |
Msg-id | 1552.1002557526@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Accessing Database files on a "read-only" medium...like a CD. ("Serguei Mokhov" <sa_mokho@alcor.concordia.ca>) |
Список | pgsql-hackers |
"Serguei Mokhov" <sa_mokho@alcor.concordia.ca> writes: > Kelly Harmon <kelly.harmon@byers.com> wrote in message news:9pr7f7$k0j$1@news.tht.net... >> 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
В списке pgsql-hackers по дате отправления: