Thread

Commits

  1. doc: Correct the timeline for OAuth's shutdown_cb

  1. [oauth] Bug: when is shutdown_cb called?

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-02-18T12:50:33Z

    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
    
  2. Re: [oauth] Bug: when is shutdown_cb called?

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-02-27T16:55:41Z

    On Wed, Feb 18, 2026 at 4:50 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
    > 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.
    
    > 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.
    
    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
    
  3. Re: [oauth] Bug: when is shutdown_cb called?

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-02-27T20:03:29Z

    > I propose the attached diff, with a backport to 18.
    
    Looks good, thanks!
    
    
    
    
  4. Re: [oauth] Bug: when is shutdown_cb called?

    Chao Li <li.evan.chao@gmail.com> — 2026-02-28T01:04:13Z

    
    > On Feb 28, 2026, at 00:55, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
    > 
    > On Wed, Feb 18, 2026 at 4:50 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
    >> 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.
    > 
    >> 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.
    > 
    > 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
    > <shutdown-docs.diff>
    
    ```
    +    The <function>shutdown_cb</function> callback is executed when the server
    +    backend has finished validating tokens for the connection. If the validator
    ```
    
    “Server backend” sounds a bit uncommon in the documentation. I searched through the *.sgml files and couldn’t find much occurrences of that phrase. It seems that “backend process” is used consistently elsewhere.
    
    Best regards,
    --
    Chao Li (Evan)
    HighGo Software Co., Ltd.
    https://www.highgo.com/
    
    
    
    
    
    
    
    
  5. Re: [oauth] Bug: when is shutdown_cb called?

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-05-29T21:50:56Z

    On Fri, Feb 27, 2026 at 5:04 PM Chao Li <li.evan.chao@gmail.com> wrote:
    > > On Feb 28, 2026, at 00:55, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
    > > I propose the attached diff, with a backport to 18.
    
    This is now pushed.
    
    > “Server backend” sounds a bit uncommon in the documentation.
    
    I suppose. We also say things like "PostgreSQL backend", "bootstrap
    backend", and of course just "server" and "backend". I don't think
    this is likely to cause any confusion, so I've kept it, but I can
    always patch+backpatch again if others feel strongly.
    
    Thanks!
    --Jacob