serializable master and non-serializable hot standby: feasible set up?

Howdy!

I've been going back and forth with the GCP CloudSQL engineering team about
the feasibility of a particular setup, and I'm pinging the list here
hoping for a sanity check. They assure me that it's impossible and I think
they must be mistaken, but I have limited experience administrating my own
postgres instances. So I'm appealing to a higher authority :)

The docs outline[1
<https://www.postgresql.org/docs/current/hot-standby.html>][2
<https://www.postgresql.org/docs/current/applevel-consistency.html#SERIALIZABLE-CONSISTENCY>]
that a hot standby / replica with the flag
`default_transaction_isolation='serializable'` is going to cause issues --
while you can connect to such an instance, basically every query against it
will fail.

But! If you can somehow manage to get the replica's flags to instead
use `repeatable
read` or `read committed` isolation, everything seems to work well, even
if the master uses `serializable` isolation. In GCP, we are having to
temporarily swap the master to a lower isolation level, then stand up the
replica and pin the lower isolation level flag, and then finally revert the
flag change on the master. If the replica goes down, we have to repeat this
process and it's a pain (not to mention data issues since our app relies on
this isolation level instead of doing explicit locking in most cases).

So I know this is an awkward question to post here, but as postgres admin
professionals, *would you* expect to be able to stand up a `repeatable
read` replica against a `serializable` master? My expectation is that you'd
simply change the setting in a .conf file on the replica and be good to go;
is there something that would make this process really difficult /
impossible?

Thanks so much!

[1]: https://www.postgresql.org/docs/current/hot-standby.html
[2]:
https://www.postgresql.org/docs/current/applevel-consistency.html#SERIALIZABLE-CONSISTENCY
--
Jake Biesinger