When continuous WAL archiving is used in a standby, there are two different scenarios: the WAL archive can be shared between the primary and the standby, or the standby can have its own WAL archive. When the standby has its own WAL archive, set archive_mode to always, and the standby will call the archive command for every WAL segment it receives, whether it's by restoring from the archive or by streaming replication. The shared archive can be handled similarly, but the archive_command must test if the file being archived exists already, and if the existing file has identical contents. This requires more care in the archive_command, as it must be careful to not overwrite an existing file with different contents, but return success if the exactly same file is archived twice. And all that must be done free of race conditions, if two servers attempt to archive the same file at the same time.
"""
The contents of both must match with respect to the data files but there are likely things that go into the master WAL stream solely for the purpose of communicating with a standby - and possibly some standby concepts that would be unique to the standby's WAL - that would cause them to differ. Not familiar enough to quickly list examples of what those might be. But IIUC the system seems designed around master->slave replication and doesn't support slave daisy-chains.
