From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Subject: | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events |
Date: | 2025-08-07 18:11:46 |
Message-ID: | CAOYmi+=9J0nA7XfUCaEdjUdAb9+L6nLoJCEGRYXZbUtZ_o2k5Q@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 7, 2025 at 9:35 AM Dagfinn Ilmari Mannsåker
<ilmari(at)ilmari(dot)org> 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_chunker, sub { print {$err} $_[0] }
> > + or die "oauth_tests returned $?";
>
> We've recently switched to using fat commas (=>) between options and
> their arguments, and that includes the file redirections in IPC::Run.
> Although not semantically meaningful, I'd also be tempted to put parens
> around the argument list for each redirect, so it's clear that they go
> together.
I have two concerns:
- If I don't put parentheses around the list, the fat comma is
actively misleading.
- As far as I can tell, IPC::Run neither documents nor tests the
ability to pass a list here. (But the tests are a bit of a maze, so
please correct me if there is one.) My fear is that I'll be coupling
against an implementation detail if I write it that way.
So I'm leaning towards keeping it as-is, unless you know of a reason
that the list syntax is guaranteed to work, with the understanding
that it does diverge from what you authored in 19c6e92b1. But I don't
think any of those examples use filters, so I don't feel too bad about
the difference yet?
> Also, indirect object syntax (print {$fh} ...) is ugly and
> old-fashioned, it's nicer to call it as a method on the filehandle.
That is much nicer; I'll do that.
> As for the C TAP tests, there's already a bunch of TAP-outputting
> infrastructure in pg_regress.c. Would it make sense to factor that out
> into a common library?
Maybe if we got to rule-of-three, but I'd rather not make either
implementation compromise for the sake of the other. IMO, this is a
situation where a bad abstraction would be much costlier than the
duplication: TAP is lightweight, and I think the needs of a unit test
suite and the needs of a characterization test collector are very
different.
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-08-07 18:19:21 | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events |
Previous Message | Jacob Champion | 2025-08-07 18:11:02 | Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events |