Re: Streaming replication, some small issues

On Tue, Dec 8, 2009 at 9:05 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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