On 2023-04-08 09:53, Daniel Gustafsson wrote:
I recommend
just setting up this one test to SKIP if IPC::Run is too old.
Yes, will do that when I have a little more time at hand for monitoring the BF
later today.
So what do you want me to do about grison and morepork? I guess I could
try
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> So what do you want me to do about grison and morepork? I guess I could
> try to install a newer version of IPC::Run from CPAN or should I just
> leave it be?
I think "leave it be" is fine.
regards, tom lane
> On 8 Apr 2023, at 02:49, Tom Lane wrote:
>
> I wrote:
>> I've been doing some checking with perlbrew locally. It appears to not
>> be about IO::Pty so much as IPC::Run: it works with IPC::Run 0.99 but
>> not 0.79. Still bisecting to identify exactly what's the minimum
>> okay version.
>
> Th
Andres Freund writes:
> On 2023-04-07 20:49:39 -0400, Tom Lane wrote:
>> IPC::Run 0.98 is relatively new (2018), so I don't think it'd fly
>> to make that our new minimum version across-the-board. I recommend
>> just setting up this one test to SKIP if IPC::Run is too old.
> Does the test actual
Hi,
On 2023-04-07 20:49:39 -0400, Tom Lane wrote:
> I wrote:
> > I've been doing some checking with perlbrew locally. It appears to not
> > be about IO::Pty so much as IPC::Run: it works with IPC::Run 0.99 but
> > not 0.79. Still bisecting to identify exactly what's the minimum
> > okay version.
I wrote:
> I've been doing some checking with perlbrew locally. It appears to not
> be about IO::Pty so much as IPC::Run: it works with IPC::Run 0.99 but
> not 0.79. Still bisecting to identify exactly what's the minimum
> okay version.
The answer is: it works with IPC::Run >= 0.98. The version
Andrew Dunstan writes:
>> Actually, one quick datapoint. prion and mantid report running IPC::Run
>> version 0.92, and morepork 0.96. Animals that pass are running 20180523.0,
>> 20200505.0, 20220807.0 or similar versions. We don't print the IO::Pty
>> version
>> during configure, but maybe th
On 2023-04-07 Fr 19:14, Daniel Gustafsson wrote:
On 8 Apr 2023, at 00:59, Daniel Gustafsson wrote:
On 8 Apr 2023, at 00:35, Tom Lane wrote:
Daniel Gustafsson writes:
On 7 Apr 2023, at 23:01, Daniel Gustafsson wrote:
Staring at this I've been unable to figure out if there an underlying p
> On 8 Apr 2023, at 00:59, Daniel Gustafsson wrote:
>
>> On 8 Apr 2023, at 00:35, Tom Lane wrote:
>>
>> Daniel Gustafsson writes:
On 7 Apr 2023, at 23:01, Daniel Gustafsson wrote:
>>> Staring at this I've been unable to figure out if there an underlying
>>> problem
>>> here or a flaky t
> On 8 Apr 2023, at 00:35, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 7 Apr 2023, at 23:01, Daniel Gustafsson wrote:
>> Staring at this I've been unable to figure out if there an underlying problem
>> here or a flaky testrun, since I can't reproduce it. Maybe the animal owner
>> (on
Daniel Gustafsson writes:
>> On 7 Apr 2023, at 23:01, Daniel Gustafsson wrote:
> Staring at this I've been unable to figure out if there an underlying problem
> here or a flaky testrun, since I can't reproduce it. Maybe the animal owner
> (on cc) have any insights?
> The test has passed on seve
> On 7 Apr 2023, at 23:01, Daniel Gustafsson wrote:
> Looks like morepork wasn't happy with the interactive \password test.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork&dt=2023-04-07%2020%3A30%3A29
>
> Looking into why the timer timed out in that test.
Staring at this I
> On 7 Apr 2023, at 22:24, Daniel Gustafsson wrote:
>
>> On 7 Apr 2023, at 18:14, Daniel Gustafsson wrote:
>>> On 7 Apr 2023, at 17:04, Andres Freund wrote:
>
>>> Afaict the failures are purely about patch 2, not 1, right?
>>
>> Correct. The attached v6 wraps the interactive_psql test in a S
> On 7 Apr 2023, at 18:14, Daniel Gustafsson wrote:
>> On 7 Apr 2023, at 17:04, Andres Freund wrote:
>> Afaict the failures are purely about patch 2, not 1, right?
>
> Correct. The attached v6 wraps the interactive_psql test in a SKIP block with
> a conditional on IO::Pty being available.
Thi
> On 7 Apr 2023, at 17:04, Andres Freund wrote:
> Afaict the failures are purely about patch 2, not 1, right?
Correct. The attached v6 wraps the interactive_psql test in a SKIP block with
a conditional on IO::Pty being available.
--
Daniel Gustafsson
v6-0002-Test-SCRAM-iteration-changes-wit
Hi,
On 2023-04-07 11:52:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-04-07 15:32:12 +0200, Daniel Gustafsson wrote:
> >> I don't think we should go ahead with a patch that refactors
> >> interactive_psql
> >> only to SKIP over it in CI (which is what the tab_completion test does
> On 7 Apr 2023, at 16:58, Andres Freund wrote:
> Note it just fails on the 32build, not the 64bit build. Unfortunately I don't
> think debian's multiarch in bullseye support installing enough of perl in
> 32bit and 64bit.
I should probably avoid parsing logfiles with fever-induced brainfog, I
c
Andres Freund writes:
> On 2023-04-07 15:32:12 +0200, Daniel Gustafsson wrote:
>> I don't think we should go ahead with a patch that refactors interactive_psql
>> only to SKIP over it in CI (which is what the tab_completion test does now),
>> so
>> let's wait until we have that sorted before goin
Hi,
On 2023-04-07 10:55:19 -0400, Andrew Dunstan wrote:
> It should probably be added to config/check_modules.pl if we're going to use
> it, but it seems to be missing for Strawberry Perl and msys/ucrt64 perl and
> I'm not sure how easy it will be to add there. It would certainly add an
> installa
Hi,
On 2023-04-07 15:32:12 +0200, Daniel Gustafsson wrote:
> > On 5 Apr 2023, at 23:44, Daniel Gustafsson wrote:
> >
> > Unless there are objections I plan to get this in before the freeze, in
> > order
> > to have better interactive tests starting with 16. With a little bit of
> > documentati
On 2023-04-07 Fr 09:32, Daniel Gustafsson wrote:
On 5 Apr 2023, at 23:44, Daniel Gustafsson wrote:
Unless there are objections I plan to get this in before the freeze, in order
to have better interactive tests starting with 16. With a little bit of
documentation polish I think it's ready.
Wh
> On 5 Apr 2023, at 23:44, Daniel Gustafsson wrote:
>
> Unless there are objections I plan to get this in before the freeze, in order
> to have better interactive tests starting with 16. With a little bit of
> documentation polish I think it's ready.
When looking at the CFBot failure on Linux a
Unless there are objections I plan to get this in before the freeze, in order
to have better interactive tests starting with 16. With a little bit of
documentation polish I think it's ready.
--
Daniel Gustafsson
> On 2 Apr 2023, at 23:37, Andres Freund wrote:
> There's this XXX that I added:
>
>> @@ -57,11 +51,10 @@ sub test_streaming
>> COMMIT;
>> });
>>
>> -$in .= q{
>> -COMMIT;
>> -\q
>> -};
>> -$h->finish;# errors make the next test fail, so ignore them here
>> +
Hi,
On 2023-04-02 22:24:16 +0200, Daniel Gustafsson wrote:
> And a v5 to fix a test failure in recovery tests.
Thanks for workin gon this!
There's this XXX that I added:
> @@ -57,11 +51,10 @@ sub test_streaming
> COMMIT;
> });
>
> - $in .= q{
> - COMMIT;
> - \q
> -
> On 31 Mar 2023, at 22:33, Daniel Gustafsson wrote:
>
> The attached v4 fixes some incorrect documentation (added by me in v3), and
> fixes that background_psql() didn't honor on_error_stop and extraparams passed
> by the user. I've also added a commit which implements the \password test
> fro
The attached v4 fixes some incorrect documentation (added by me in v3), and
fixes that background_psql() didn't honor on_error_stop and extraparams passed
by the user. I've also added a commit which implements the \password test from
the SCRAM iteration count patchset as well as cleaned up a few I
> On 18 Mar 2023, at 23:07, Andrew Dunstan wrote:
> BTW, a better test than the one above would be
>
>$package->isa("PostgreSQL::Test::Cluster")
Attached is a quick updated v3 of the patch which, to the best of my Perl
abilities, tries to address the comments raised here.
--
Daniel Gustafs
On 2023-03-17 Fr 18:58, Andres Freund wrote:
Hi,
On 2023-03-17 12:25:14 -0400, Andrew Dunstan wrote:
On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
If we are going to keep this as a separate package, then we should put some
code in the constructor to prevent it being called from elsewhere
Hi,
On 2023-03-17 12:25:14 -0400, Andrew Dunstan wrote:
> On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
> > > If we are going to keep this as a separate package, then we should put
> > > some code in the constructor to prevent it being called from elsewhere
> > > than the Cluster package. e.g
On 2023-03-17 Fr 14:07, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
Why is $restart_before_query a package/class level value instead of
an instance value? And why can we only ever set it to 1 but not back
again? Maybe we don't want
Andrew Dunstan writes:
> On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
>>> Why is $restart_before_query a package/class level value instead of
>>> an instance value? And why can we only ever set it to 1 but not back
>>> again? Maybe we don't want to, but it looks odd.
>> It was mostly a POC to
On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
A common perl idiom is to start private routine names with an underscore. so
I'd rename wait_connect to _wait_connect;
There are quite a few routines documented as internal in Cluster.pm which don't
start with an underscore. Should we change
> On 17 Mar 2023, at 14:48, Andrew Dunstan wrote:
> On 2023-03-17 Fr 05:48, Daniel Gustafsson wrote:
>>> On 15 Mar 2023, at 02:03, Andres Freund
>>> wrote:
>>>
Returning a hash seems like a worse option since it will complicate
callsites
which only want to know success/failure.
On 2023-03-17 Fr 05:48, Daniel Gustafsson wrote:
On 15 Mar 2023, at 02:03, Andres Freund wrote:
Returning a hash seems like a worse option since it will complicate callsites
which only want to know success/failure.
Yea. Perhaps it's worth having a separate function for this? ->query_rc() or
> On 15 Mar 2023, at 02:03, Andres Freund wrote:
>> Returning a hash seems like a worse option since it will complicate callsites
>> which only want to know success/failure.
>
> Yea. Perhaps it's worth having a separate function for this? ->query_rc() or
> such?
If we are returning a hash then
On 2023-01-30 Mo 19:00, Andres Freund wrote:
Hi,
On 2023-01-30 15:06:46 -0500, Tom Lane wrote:
Andres Freund writes:
It's annoyingly hard to wait for the result of a query in a generic way with
background_psql(), and more generally for psql. background_psql() uses -XAtq,
which means that we'
Hi,
On 2023-03-14 21:24:32 +0100, Daniel Gustafsson wrote:
> > On 31 Jan 2023, at 01:00, Andres Freund wrote:
>
> > I've hacked some on this. I first tried to just introduce a few helper
> > functions in Cluster.pm, but that ended up being awkward. So I bit the
> > bullet
> > and introduced a n
> On 31 Jan 2023, at 01:00, Andres Freund wrote:
> I've hacked some on this. I first tried to just introduce a few helper
> functions in Cluster.pm, but that ended up being awkward. So I bit the bullet
> and introduced a new class (in BackgroundPsql.pm), and made background_psql()
> and interacti
Hi,
On 2023-01-30 15:06:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It's annoyingly hard to wait for the result of a query in a generic way with
> > background_psql(), and more generally for psql. background_psql() uses
> > -XAtq,
> > which means that we'll not get "status" output (lik
Andres Freund writes:
> It's annoyingly hard to wait for the result of a query in a generic way with
> background_psql(), and more generally for psql. background_psql() uses -XAtq,
> which means that we'll not get "status" output (like "BEGIN" or "(1 row)"),
> and that queries not returning anythi
Hi,
Plenty tap tests require a background psql. But they're pretty annoying to
use.
I think the biggest improvement would be an easy way to run a single query and
get the result of that query. Manually having to pump_until() is awkward and
often leads to hangs/timeouts, instead of test failures,
42 matches
Mail list logo
