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
