Re: Refactoring postmaster's code to cleanup after child exit - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Refactoring postmaster's code to cleanup after child exit
Date
Msg-id 31b798ca-c150-4fc9-befe-300dd8bbda3c@iki.fi
Whole thread Raw
In response to Re: Refactoring postmaster's code to cleanup after child exit  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
On 09/12/2024 01:12, Tomas Vondra wrote:
> On 11/14/24 15:13, Heikki Linnakangas wrote:
>> On 09/10/2024 23:40, Heikki Linnakangas wrote:
>>> I pushed the first three patches, with the new test and one of the small
>>> refactoring patches. Thanks for all the comments so far! Here is a new
>>> version of the remaining patches.
>>>
> Hi, the TAP test 001_connection_limits.pl introduced by 6a1d0d470e84
> seems to have problems with valgrind :-( I reliably get this failure:

How exactly do you run the test with valgrind? What platform?

It works for me, with this:

(cd build && ninja && rm -rf tmp_install && meson test --suite setup && 
valgrind --leak-check=no --gen-suppressions=all 
--suppressions=/home/heikki/git-sandbox/postgresql/src/tools/valgrind.supp 
--time-stamp=yes 
--error-markers=VALGRINDERROR-BEGIN,VALGRINDERROR-END 
--log-file=$HOME/pg-valgrind/%p.log --trace-children=yes meson test 
--suite postmaster )

> t/001_connection_limits.pl .. 3/? # Tests were run but no plan was
> declared and done_testing() was not seen.
> # Looks like your test exited with 29 just after 4.
> t/001_connection_limits.pl .. Dubious, test returned 29 (wstat 7424, 0x1d00)
> All 4 subtests passed
> 
> 
> and tmp_check/log/regress_log_001_connection_limits says:
> 
> 
> [23:48:44.444](1.129s) ok 3 - reserved_connections limit
> [23:48:44.445](0.001s) ok 4 - reserved_connections limit: matches
> process ended prematurely at
> /home/user/work/postgres/src/test/postmaster/../../../src/test/perl/PostgreSQL/Test/BackgroundPsql.pm
> line 154.
> # Postmaster PID for node "primary" is 198592
> 
> 
> That BackgroundPsql.pm line is this in wait_connect()
> 
>    $self->{run}->pump()
>      until $self->{stdout} =~ /$banner/ || $self->{timeout}->is_expired;
> 
> By trial and error I found that it fails on this line 70:
> 
>    push(@sessions, background_psql_as_user('regress_superuser'));
> 
> but I have no idea idea why. There are multiple similar calls a couple
> lines earlier, and those work fine. And various other TAP tests with
> background_sql() work fine too.
> 
> So what's so special about this particular line?

Weird. Valgrind makes everything slow; is it a timeout? Any other clues 
in the logs?

-- 
Heikki Linnakangas
Neon (https://neon.tech)



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: An inefficient query caused by unnecessary PlaceHolderVar
Next
From: Bertrand Drouvot
Date:
Subject: Re: Track the amount of time waiting due to cost_delay