PG-1866 Reset WAL key cache on shmem init

It seems like there are cases when the postmaster have "restarted"
after a backend crash where the wal cache inherited from the postmaster
is wrong.

I'm not at all sure exactly how and why this happens, but this patch
fixes a bug with this and allows recovery/013_crash_restart to pass with
WAL encryption enabled.

contrib/pg_tde/src/access/pg_tde_xlog_keys.c

@@ -72,6 +72,23 @@ get_wal_key_file_path(void)
 	return wal_key_file_path;
 }
 
+void
+pg_tde_free_wal_key_cache(void)
+{
+	WALKeyCacheRec *rec = tde_wal_key_cache;
+
+	while (rec != NULL)
+	{
+		WALKeyCacheRec *next = rec->next;
+
+		pfree(rec);
+		rec = next;
+	}
+
+	tde_wal_key_cache = NULL;
+	tde_wal_key_last_rec = NULL;
+}
+
 void
 pg_tde_wal_last_key_set_location(WalLocation loc)
 {

contrib/pg_tde/src/access/pg_tde_xlog_smgr.c

@@ -220,9 +220,18 @@ TDEXLogSmgrInit()
 void
 TDEXLogSmgrInitWrite(bool encrypt_xlog)
 {
-	WalEncryptionKey *key = pg_tde_read_last_wal_key();
+	WalEncryptionKey *key;
 	WALKeyCacheRec *keys;
 
+	/*
+	 * If the postmaster have done a "soft" restart after a backend crash, we
+	 * may have inherited the cache in a weird state. Clearing the cache here
+	 * ensures we reinitialize all keys from disk.
+	 */
+	pg_tde_free_wal_key_cache();
+
+	key = pg_tde_read_last_wal_key();
+
 	/*
 	 * Always generate a new key on starting PostgreSQL to protect against
 	 * attacks on CTR ciphers based on comparing the WAL generated by two

contrib/pg_tde/src/include/access/pg_tde_xlog_keys.h

@@ -74,6 +74,7 @@ extern int	pg_tde_count_wal_keys_in_file(void);
 extern void pg_tde_create_wal_key(WalEncryptionKey *rel_key_data, WalEncryptionKeyType entry_type);
 extern void pg_tde_delete_server_key(void);
 extern WALKeyCacheRec *pg_tde_fetch_wal_keys(WalLocation start);
+extern void pg_tde_free_wal_key_cache(void);
 extern WALKeyCacheRec *pg_tde_get_last_wal_key(void);
 extern TDESignedPrincipalKeyInfo *pg_tde_get_server_key_info(void);
 extern WALKeyCacheRec *pg_tde_get_wal_cache_keys(void);