pg_receivewal support?

[leventov]

Description

Is there a fundamental limitation due to which pg_tde doesn't support pg_receivewal, or this feature is just not implemented yet?

Suggested solution

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[dAdAbird]

Hi @leventov, sorry for the late reply.

No limitation afaik, it's just not implemented yet. We had other priorities for the release, and pg_receivewal wasn't among them.

[dAdAbird]

BTW, can I ask about your usage scenarios for pg_receivewal? It's for us to understand use cases, so we can better prioritise things for the next releases.

[leventov]

My overarching goal: near-zero "recovery point objective" via using a backup system together with some ad-hoc pg_receivewal-based replication, as described here:

Or, really, you could just run pg_receivewal and have it spool into a directory and then just periodically clean it up, perhaps having whatever script that does that check that a given WAL is in the pgbackrest repo first before removing it.

The most difficult and potentially buggy part of all of this would be on the restore side, really, since you'd have to adjust the restore command to check for a WAL file being in this other spool area if pgbackrest doesn't find it. Certainly not impossible but would be annoying. All of this hand-hacking is strongly discouraged though and, again, a much, much better design would be to have a sync replica for this use-case. Simply having a sync replica would give address this use-case and is much better tested than any of the other approaches and much less likely to lead to a surprise somewhere along the way.

To answer to the latter part of this message: entire sync replica is out of the question because the target use case is "personal" database (one database per user) hosted in fly.io where hosting an entire sync replica (also one per user) would cost extra ~3$/mo, which is non-trivial and would reduce users' appetite for the service quite a lot.