Subject: Re: Periodic authorization expiration checks using GoAway message

From: Zsolt Parragi <[email-masked]>
Date: Tue, 3 Feb 2026 19:16:09 +0000

Hello!

I did some manual testing of the patch, and found a few more issues / questions.

I think it would be a good idea to add a tap test at this point to
make sure that every corner case works properly.

1. CheckPasswordExpiration doesn't verify that the connection uses
password authentication or not, it always updates the valid date and
starts enforcing it - it should have an additional check at the
beginning to only continue if password_valid_until_timestamp > 0,
otherwise it should just reset AuthCheckNeeded

For example, currently:

* I created a user with a password expiration in the past, logged in
using trust authentication - login worked without problems
* Changed the password expiration of another user, the previous
session got terminated because of the expired password

2. it is triggered if any user gets changed, not just the current user
- on a server with many users, this could be a performance issue as
we'll end up doing unnecessary syscache lookups. This could be
optimized by caching the syscache hash in a variable. (but this is
based on what do you think about the next point)

Again see the previous example problem - I changed the expiration date
of one user, and another user was kicked out because of this, while
that user didn't receive any updates

3. The check is based on GetUserId() and not GetSessionUserId() - if I
change roles with SET ROLE, password expiration checks will verify the
role user, and not the logged in user. This seems strange to me: if we
logged in with a password, after a SET ROLE, we'll enforce password
expiration based on the new role - but we never actually used the
password of that role. Are you sure this is how it should work?