On Thu, Aug 7, 2025 at 1:45 PM Thomas Munro wrote:
> I like the C TAP test. PostgreSQL
> needs more of this.
I should add, I didn't look closely at that part since you said it's
not in scope for back-patching. I'd like to, though, later.
I wonder if you would be interested in this attempt at c
On Thu, Aug 7, 2025 at 11:55 AM Jacob Champion
wrote:
> On Wed, Aug 6, 2025 at 9:13 AM Jacob Champion
> wrote:
> > Maybe "drain" would no longer be the
> > verb to use there.
>
> I keep describing this as "combing" the queue when I talk about it in
> person, so v3-0001 renames this new operation
On Wed, Aug 6, 2025 at 9:13 AM Jacob Champion
wrote:
> Maybe "drain" would no longer be the
> verb to use there.
I keep describing this as "combing" the queue when I talk about it in
person, so v3-0001 renames this new operation to comb_multiplexer().
And the CI (plus the more strenuous TLS tests
On Wed, Aug 6, 2025 at 8:04 AM Thomas Munro wrote:
> * If it returns 1, then it stopped on the first level-triggered event
> that it rechecked and found to be still true. Who cares if there are
> more that didn't get rechecked? poll(fd) will report POLLIN either
> way, and that's what you want.
On Tue, Aug 5, 2025 at 3:24 AM Jacob Champion
wrote:
> On Mon, Aug 4, 2025 at 7:53 AM Thomas Munro wrote:
> > [FYI, I'm looking into this and planning to post a review in 1-2 days...]
0001:
So, the problem is that poll(kqueue_fd) reports POLLIN if any events
are queued, but level-triggered even
On Mon, Aug 4, 2025 at 7:53 AM Thomas Munro wrote:
> [FYI, I'm looking into this and planning to post a review in 1-2 days...]
Thanks so much!
--Jacob
On Tue, Jul 29, 2025 at 8:52 AM Jacob Champion
wrote:
> On Thu, Jun 26, 2025 at 4:33 PM Jacob Champion
> wrote:
> > My plan, if this code seems reasonable, is to backport 0001-0003, but
> > keep the larger 0004 on HEAD only until it has proven to be stable.
> > It's a big new suite and I want to
Hi all,
On Thu, Jun 26, 2025 at 4:33 PM Jacob Champion
wrote:
> My plan, if this code seems reasonable, is to backport 0001-0003, but
> keep the larger 0004 on HEAD only until it has proven to be stable.
> It's a big new suite and I want to make sure it's not flapping on some
> buildfarm animal.
Hi all,
The current implementation of the OAuth flow is overly eager to signal
readiness when there's nothing to do, so sometimes we burn CPU for no
reason. This was discussed briefly back in [1], but I'll summarize
here so no one has to dig through that megathread.
= Background =
A major intera
