| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
| Date: | 2025-03-07 05:12:50 |
| Message-ID: | CA+hUKGKmyShTB_rDmn3Zy-+9-iNFeMJZnS9iMMHFtUAohjK=Ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 7, 2025 at 9:57 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> 2) macOS's EVFILT_TIMER implementation seems to be different from the
> other BSDs. On Mac, when you re-add a timer to a kqueue, any existing
> timer-fired events for it are not cleared out and the kqueue might
> remain readable. This breaks a postcondition of our set_timer()
> function, which is that new timeouts are supposed to completely
> replace previous timeouts.
I don't see that behaviour on my Mac with a simple program, and that
seems like it couldn't possibly be intended. Hmm... <browses source
code painfully> I wonder if this atomic generation scheme has a hole
in it, under concurrency...
The code on the other OSes just dequeues it when reprogramming the
timer, which involves a lock and no doubt a few more cycles, and is
clearly not quite as exciting but ...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-03-07 05:42:13 | Re: per backend WAL statistics |
| Previous Message | Peter Smith | 2025-03-07 05:05:00 | Re: Parallel heap vacuum |