Subject: [oauth] Bug: when is shutdown_cb called?

From: Zsolt Parragi <[email-masked]>
Date: Wed, 18 Feb 2026 12:50:33 +0000

Hello

>From the documentation[1]:

> The shutdown_cb callback is executed when the backend process associated with the connection exits. If the validator module has any allocated state, this callback should free it to avoid resource leaks.

But it actually gets called when the memory context used during
authentication is cleaned up, immediately after authentication
completes.

I attached a patch that moves it to the actual backend exit, but I'm
not sure if this is the good approach.

The advantages: things like expiration checks[2], or repeated
validation in the future when we implement token refresh need a
working validator state, which means either we have to call
startup/shutdown multiple times, or keep the context. It also behaves
exactly like how the 18.x documentation explains it.

The disadvantages:

1. This is just a shmem exit hook, a validator could register it in
_PG_init anyway

2. The current memory context during the startup / validate callbacks
wasn't TopMemoryContext, so I changed that in the patch. Otherwise
anything allocated in them wouldn't exist in shutdown, creating all
kinds of bugs, as that would be way too easy to overlook.

Maybe we should just fix the documentation instead?

[1] : https://www.postgresql.org/docs/current/oauth-validator-callbacks.html#OAUTH-VALIDATOR-CALLBACK-SHUTDOWN
[2] : https://www.postgresql.org/message-id/CAER375PhG5an%3Dp1%3D6QS6vWi%3DBHxR%2BViJmYPDkkEtpgVsfCcu_w%40mail.gmail.com

---

From: Jacob Champion <[email-masked]>
Date: Fri, 27 Feb 2026 08:55:41 -0800

> Maybe we should just fix the documentation instead?

Yeah, this is just a docs bug. It changed in v47 of the original
patchset [1] but I forgot to update the documentation. (It was
originally a before_shmem_exit implementation, which is why that fits
the description well. :D)

I propose the attached diff, with a backport to 18.

> startup/shutdown multiple times, or keep the context.

Personally I think it's fine for more complicated behavior to require
more integration into the existing server APIs. We don't need to
reinvent OAuth-specific wheels; implementations will just need to pay
attention to memory contexts and _PG_init like standard extensions
already do.

Thanks,
--Jacob

[1] https://www.postgresql.org/message-id/CAOYmi%2BnHG7oy%2BybHH72WjiXAQG3tE6v_at-K9ebRy2oqo92V%2BA%40mail.gmail.com

---

From: Zsolt Parragi <[email-masked]>
Date: Fri, 27 Feb 2026 20:03:29 +0000

> I propose the attached diff, with a backport to 18.

Looks good, thanks!