Hi Zsolt, Thanks a lot for your review comments.
>After one more look at this, shouldn't we refresh the cache if AuthCheckNeeded, regardless of the valid until timestamp value? (for example by moving the >0 condition to the inner if) Done. I agree and I handled the scenario in the updated patch. >I missed this in my previos review, the error message should start with a lowercase character Done. >if the user was dropped, but the connection is still active, the patch silently ignores it. That matches the current behavior of postgres, but is that the expected behavior in the context of this patch? Thanks a lot for this use case. I agree that this patch should handle that scenario more explicitly. I have updated the logic in the attached version to address this use case. I have attached an updated patch. Request a review. Thanks & Best Regards, Ajit On Thu, 22 Jan 2026 at 13:10, Zsolt Parragi <[email protected]> wrote: > Hello! > > > Done. I have modified the condition check so as it will not impact users > > having rolvaliduntil to NULL. > > Thanks! After one more look at this, shouldn't we refresh the cache if > AuthCheckNeeded, regardless of the valid until timestamp value? (for > example by moving the >0 condition to the inner if) > > Consider the following scenario: > > 1. user logs in, without a valid until date set > 2. valid until is set to something > 3. existing session started in 1 will never be terminated > > > postgres.c:5368 - I missed this in my previos review, the error > message should start with a lowercase character. > > > > This patch introduces a mechanism to address the security issue of stale, > > authorized connections persisting beyond their validity period. . > > postgres.c:5326 - if the user was dropped, but the connection is still > active, the patch silently ignores it. That matches the current > behavior of postgres, but is that the expected behavior in the context > of this patch? >
password_expiration_enforcement_V2.diff
Description: Binary data
