On Tue, Dec 8, 2009 at 9:05 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >> I suspect we should have a WAL record to say "unlogged operation >> performed here" which a standby database would recognize and throw a >> large warning up. > > +1. Seems like a very simple solution.
Sounds good. This is not just a problem of SR, so I'll implement it as self-contained feature later. Design: - If relation is not temp and archiving (and streaming replication) is enabled, we log the "unlogged OP" record including relfilenode of the relation. - If "unlogged OP" record is found during archive recovery, we register its relfilenode to the hashtable which tracks maybe corrupted relations. If the registered relfilenode is brandnew, we emit warning. Also, the log record indicating "DROP TABLE" etc is found, we remove its relfilenode from the hashtable. - When restartpoint occurs, we write all the registered relfilenodes to the flat file. - At the end of archive recovery, if there is relfilenode in the hashtable, we emit FATAL error to prevent the server from being brought up. XXX: But this might be too conservative. I believe that some people want to complete archive recovery even if a relation is corrupted, and drop that relation after the server has been activated. So I'm going to provide new recovery.conf parameter specifying whether to let archive recovery fail when some relations might be corrupted. Thought? Am I missing something? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers