Hi,
On 2021-12-29 23:06:31 -0800, SATYANARAYANA NARLAPURAM wrote:
> I am afraid there are problems with making the RPO check post releasing the
> locks. By this time the transaction is committed and visible to the other
> backends (ProcArrayEndTransaction is already called) though the intention
> is to block committing transactions that violate the defined RPO.
Shrug. Anything transaction based has way bigger holes than this.
> Even though we block existing connections starting a new transaction, it is
> possible to do writes by opening a new connection / canceling the query.
If your threat model is users explicitly trying to circumvent this they can
cause problems much more easily. Trigger a bunch of vacuums, big COPYs etc.
> I am not too much worried about the lock contention as the system is already
> hosed because of the policy. This behavior is very similar to what happens
> when the Sync standby is not responding. Thoughts?
I don't see why we'd bury ourselves deeper in problems just because we already
have a problem. There's reasons why we want to do the delay for syncrep be
before xact completion - but I don't see those applying to WAL throttling to a
significant degree, particularly not when it's on a transaction level.
Greetings,
Andres Freund