On 2025-08-12 Tu 6:25 PM, Jacob Champion wrote:
On Tue, Aug 12, 2025 at 3:21 PM Andrew Dunstan wrote:
I don't think that's quite going to work. The buildfarm will now get a
"target not found" in the without-curl case, I suspect. I think you'll
need an alternative definition of the check targ
On Tue, Aug 12, 2025 at 3:21 PM Andrew Dunstan wrote:
> I don't think that's quite going to work. The buildfarm will now get a
> "target not found" in the without-curl case, I suspect. I think you'll
> need an alternative definition of the check target.
We're still including Makefile.global, so
On 2025-08-12 Tu 6:11 PM, Jacob Champion wrote:
On Fri, Aug 8, 2025 at 2:31 PM Jacob Champion
wrote:
Well, thank you for the explanation. I'll make that change.
Done in v5.
v5-0001 is planned for backport to 18 once the freeze lifts. It
ensures that -lm is part of the link line for libpq-oa
On Fri, Aug 8, 2025 at 2:31 PM Jacob Champion
wrote:
> Well, thank you for the explanation. I'll make that change.
Done in v5.
v5-0001 is planned for backport to 18 once the freeze lifts. It
ensures that -lm is part of the link line for libpq-oauth, since the
module uses floor(). I probably woul
On Fri, Aug 8, 2025 at 2:16 PM Dagfinn Ilmari Mannsåker
wrote:
> That's because encode_json has a prototype[1], which changes how the
> argument list is parsed: no longer just as a flat list of values like a
> normal function. Specifically, it has a prototype of '$', which means
> it only takes o
Jacob Champion writes:
> On Fri, Aug 8, 2025 at 1:07 PM Dagfinn Ilmari Mannsåker
> wrote:
>> $ perl -MJSON::PP=encode_json -E 'say encode_json([1, 2, 3])'
>> [1,2,3]
>>
>> $ perl -MJSON::PP=encode_json -E 'say encode_json([1 => (2, 3)])'
>> [1,2,3]
>
> I swear, this language.
>
>
On Fri, Aug 8, 2025 at 1:07 PM Dagfinn Ilmari Mannsåker
wrote:
> $ perl -MJSON::PP=encode_json -E 'say encode_json([1, 2, 3])'
> [1,2,3]
>
> $ perl -MJSON::PP=encode_json -E 'say encode_json([1 => (2, 3)])'
> [1,2,3]
I swear, this language.
But:
$ perl -MJSON::PP=encode_json
Jacob Champion writes:
> On Thu, Aug 7, 2025 at 9:35 AM Dagfinn Ilmari Mannsåker
> wrote:
>> I haven't read the meat of the patch, but I have some comments on the
>> tests:
>
> Thanks for the review!
>
>> > +IPC::Run::run ['oauth_tests'],
>> > + '>', IPC::Run::new_chunker, sub { print {$out} $_
On Fri, Aug 8, 2025 at 3:39 AM Thomas Munro wrote:
> LGTM.
Committed!
Thanks,
--Jacob
On Fri, Aug 8, 2025 at 8:04 AM Jacob Champion
wrote:
> On Thu, Aug 7, 2025 at 11:11 AM Jacob Champion
> wrote:
> > Thank you so much for the reviews!
>
> Here is v4, with the feedback from both of you. 0001-0004 are planned
> for backport; 0005 is slated for master only. Thanks again for the
> re
On Thu, Aug 7, 2025 at 11:11 AM Jacob Champion
wrote:
> Thank you so much for the reviews!
Here is v4, with the feedback from both of you. 0001-0004 are planned
for backport; 0005 is slated for master only. Thanks again for the
reviews!
--Jacob
1: c5cdccfe374 ! 1: a515435d3b4 oauth: Remove sta
On Wed, Aug 6, 2025 at 7:43 PM Thomas Munro wrote:
> On Thu, Aug 7, 2025 at 1:45 PM Thomas Munro wrote:
> I wonder if you would be interested in this attempt at centralised
> infrastructure for unit testing our C code over here. I'm not
> suggesting it for your immediate problem, just noting the
On Wed, Aug 6, 2025 at 6:46 PM Thomas Munro wrote:
> "Unlike epoll descriptors, kqueue descriptors only transition from
> readable to unreadable when kevent() is called and finds nothing,
> after removing level-triggered conditions that have gone away. We
> therefore need a dummy kevent() call af
On Thu, Aug 7, 2025 at 9:35 AM Dagfinn Ilmari Mannsåker
wrote:
> I haven't read the meat of the patch, but I have some comments on the
> tests:
Thanks for the review!
> > +IPC::Run::run ['oauth_tests'],
> > + '>', IPC::Run::new_chunker, sub { print {$out} $_[0] },
> > + '2>', IPC::Run::new_chu
Jacob Champion writes:
> From 50257bf32eb2b0972e5139ac4a79367372c77385 Mon Sep 17 00:00:00 2001
> From: Jacob Champion
> Date: Wed, 5 Mar 2025 15:04:34 -0800
> Subject: [PATCH v3 5/5] oauth: Add unit tests for multiplexer handling
I haven't read the meat of the patch, but I have some comments o
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
24 matches
Mail list logo
