In short, all the 4 patches look good to me. Thanks for picking this up!
On 06/03/2025 22:16, Andres Freund wrote:
On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
This behaviour makes it really hard to debug problems. It'd have been a lot
easier to understand the problem if we'd seen psql's std
Hi,
On 2025-03-07 18:03:04 +0100, Tomas Vondra wrote:
> On 3/7/25 16:49, Andres Freund wrote:
> > Hi,
> >
> > On 2025-03-07 16:25:09 +0100, Tomas Vondra wrote:
> >> FWIW I keep running into this (and skink seems unhappy too). I ended up
> >> just adding a sleep(1), right before
> >>
> >> push(@se
On 3/7/25 16:49, Andres Freund wrote:
> Hi,
>
> On 2025-03-07 16:25:09 +0100, Tomas Vondra wrote:
>> FWIW I keep running into this (and skink seems unhappy too). I ended up
>> just adding a sleep(1), right before
>>
>> push(@sessions, background_psql_as_user('regress_superuser'));
>>
>> and that m
On 3/7/25 15:53, Andres Freund wrote:
> Hi,
>
> On 2025-03-06 22:49:20 +0200, Heikki Linnakangas wrote:
>> In short, all the 4 patches look good to me. Thanks for picking this up!
>>
>> On 06/03/2025 22:16, Andres Freund wrote:
>>> On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
> This behavio
Hi,
On 2025-03-07 16:25:09 +0100, Tomas Vondra wrote:
> FWIW I keep running into this (and skink seems unhappy too). I ended up
> just adding a sleep(1), right before
>
> push(@sessions, background_psql_as_user('regress_superuser'));
>
> and that makes it work on all my machines (including rpi5)
Hi,
On 2025-03-06 22:49:20 +0200, Heikki Linnakangas wrote:
> In short, all the 4 patches look good to me. Thanks for picking this up!
>
> On 06/03/2025 22:16, Andres Freund wrote:
> > On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
> > > > This behaviour makes it really hard to debug problems. I
On 05/03/2025 01:23, Michael Paquier wrote:
On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
backend shows up in pg_stat_activity before it acquires
Hi,
On 2025-03-05 20:49:33 -0800, Noah Misch wrote:
> > This behaviour makes it really hard to debug problems. It'd have been a lot
> > easier to understand the problem if we'd seen psql's stderr before the test
> > died.
> >
> > I guess that mean at the very least we'd need to put an eval {} aro
On Tue, Mar 04, 2025 at 05:50:34PM -0500, Andres Freund wrote:
> On 2024-12-09 00:12:32 +0100, Tomas Vondra wrote:
> > [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/
On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
> On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
>> 2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
>> backend shows up in pg_stat_activity before it acquires a PGPROC entry, and
>> stays visible un
Hi,
On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
> On 09/12/2024 22:55, Heikki Linnakangas wrote:
> > Not sure how to fix this. A small sleep in the test would work, but in
> > principle there's no delay that's guaranteed to be enough. A more robust
> > solution would be to run a "selec
Hi,
On 2024-12-09 00:12:32 +0100, Tomas Vondra wrote:
> Hi, the TAP test 001_connection_limits.pl introduced by 6a1d0d470e84
> seems to have problems with valgrind :-( I reliably get this failure:
>
>
> t/001_connection_limits.pl .. 3/? # Tests were run but no plan was
> declared and done_testin
On 12/10/24 11:00, Heikki Linnakangas wrote:
> On 09/12/2024 22:55, Heikki Linnakangas wrote:
>> Not sure how to fix this. A small sleep in the test would work, but in
>> principle there's no delay that's guaranteed to be enough. A more
>> robust solution would be to run a "select count(*) from
On 09/12/2024 22:55, Heikki Linnakangas wrote:
Not sure how to fix this. A small sleep in the test would work, but in
principle there's no delay that's guaranteed to be enough. A more robust
solution would be to run a "select count(*) from pg_stat_activity" and
wait until the number of connecti
On 09/12/2024 14:47, Tomas Vondra wrote:
On 12/9/24 13:30, Heikki Linnakangas wrote:
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
re
On 12/9/24 13:30, Heikki Linnakangas wrote:
> 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. Than
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 rem
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 tes
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.
Lots of little cleanups and changes here and there since the last
versi
Hi,
On Tue, 8 Oct 2024 at 00:55, Heikki Linnakangas wrote:
>
> On 05/10/2024 22:51, Dagfinn Ilmari Mannsåker wrote:
> > Heikki Linnakangas writes:
> >> Sadly Windows' IO::Socket::UNIX hasn't been implemented on Windows (or
> >> at least on this perl distribution we're using in Cirrus CI):
> >>
>
On 05/10/2024 22:51, Dagfinn Ilmari Mannsåker wrote:
Heikki Linnakangas writes:
Sadly Windows' IO::Socket::UNIX hasn't been implemented on Windows (or
at least on this perl distribution we're using in Cirrus CI):
Socket::pack_sockaddr_un not implemented on this architecture at
C:/strawberry/5.
Hi,
On 2024-10-05 20:51:50 +0100, Dagfinn Ilmari Mannsåker wrote:
> Socket version 2.028 (included in Perl 5.32) provides pack_sockaddr_un()
> on Windows, so that can be fixed by bumping the Perl version in
> https://github.com/anarazel/pg-vm-images/blob/main/packer/windows.pkr.hcl
> to something
Heikki Linnakangas writes:
> On 05/10/2024 01:03, Thomas Munro wrote:
>
>> It's possible that Windows copied the Linux behaviour for AF_UNIX,
>> given that it probably has something to do with the WSL project for
>> emulating Linux, but IDK.
>
> Sadly Windows' IO::Socket::UNIX hasn't been impleme
On 05/10/2024 01:03, Thomas Munro wrote:
On Sat, Oct 5, 2024 at 7:41 AM Heikki Linnakangas wrote:
My test for dead-end backends opens 20 TCP (or unix domain) connections
to the server, in quick succession. That works fine my system, and it
passed cirrus CI on other platforms, but on FreeBSD it
On Sat, Oct 5, 2024 at 7:41 AM Heikki Linnakangas wrote:
> My test for dead-end backends opens 20 TCP (or unix domain) connections
> to the server, in quick succession. That works fine my system, and it
> passed cirrus CI on other platforms, but on FreeBSD it failed
> repeatedly. The behavior in t
On 06/09/2024 12:52, Heikki Linnakangas wrote:
Unless you have comments on these first two patches which just add
tests, I'll commit them shortly. Still processing the rest of your
comments...
Didn't happen as "shortly" as I thought..
My test for dead-end backends opens 20 TCP (or unix domain
Hi,
On 2024-09-10 13:33:36 -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 12:59 PM Andres Freund wrote:
> > I still think that we'd be better off to just return an error to the client
> > in
> > postmaster, rather than deal with this dead-end children mess. That was
> > perhaps justified at
Hi,
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
> @@ -2864,6 +2777,8 @@ PostmasterStateMachine(void)
>*/
> if (pmState == PM_STOP_BACKENDS)
> {
> + uint32 targetMask;
> +
> /*
>* Forget any pending requests for back
On Tue, Sep 10, 2024 at 12:59 PM Andres Freund wrote:
> I still think that we'd be better off to just return an error to the client in
> postmaster, rather than deal with this dead-end children mess. That was
> perhaps justified at some point, but now it seems to add way more complexity
> than it'
Hi,
On 2024-09-06 16:13:43 +0300, Heikki Linnakangas wrote:
> On 04/09/2024 17:35, Andres Freund wrote:
> > On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
> > > From dc53f89edbeec99f8633def8aa5f47cd98e7a150 Mon Sep 17 00:00:00 2001
> > > From: Heikki Linnakangas
> > > Date: Mon, 12 Aug
On Fri, Sep 6, 2024 at 9:13 AM Heikki Linnakangas wrote:
> It's currently possible to have up to 2 * max_connections backends in
> the authentication phase. We would have to change that behaviour, or
> make the PGPROC array 2x larger.
I know I already said this elsewhere, but in case it got lost
On 04/09/2024 17:35, Andres Freund wrote:
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
From dc53f89edbeec99f8633def8aa5f47cd98e7a150 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Mon, 12 Aug 2024 10:59:04 +0300
Subject: [PATCH v4 4/8] Introduce a separate BackendType for d
On 04/09/2024 17:35, Andres Freund wrote:
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
+Running the tests
+=
+
+NOTE: You must have given the --enable-tap-tests argument to configure.
+
+Run
+make check
+or
+make installcheck
+You can use "make installcheck" if
Hi,
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
> While rebasing this today, I spotted another instance of that mistake
> mentioned in the XXX comment above. I called "CountChildren(B_BACKEND)"
> instead of "CountChildren(1 << B_BACKEND)". Some ideas on how to make that
> less error-pr
On 18/08/2024 11:00, Alexander Lakhin wrote:
10.08.2024 00:13, Heikki Linnakangas wrote:
Committed the patches up to and including this one, with tiny comment changes.
I've noticed that on the current HEAD server.log contains binary data
(an invalid process name) after a child crash. For exam
Hello Heikki,
10.08.2024 00:13, Heikki Linnakangas wrote:
Committed the patches up to and including this one, with tiny comment changes.
I've noticed that on the current HEAD server.log contains binary data
(an invalid process name) after a child crash. For example, while playing
with -ftapv,
On 08/08/2024 13:47, Thomas Munro wrote:
On Windows, if a child process exits with ERROR_WAIT_NO_CHILDREN, it's
now logged with that exit code, instead of 0. Also, if a bgworker
exits with ERROR_WAIT_NO_CHILDREN, it's now treated as crashed and is
restarted. Previously it was
On Fri, Aug 2, 2024 at 11:57 AM Heikki Linnakangas wrote:
> * v3-0001-Make-BackgroundWorkerList-doubly-linked.patch
LGTM.
> [v3-0002-Refactor-code-to-handle-death-of-a-backend-or-bgw.patch]
Currently, when a child process exits, the postmaster first scans
through BackgroundWorkerList, t
On 06/07/2024 22:01, Heikki Linnakangas wrote:
Reading through postmaster code, I spotted some refactoring
opportunities to make it slightly more readable.
Currently, when a child process exits, the postmaster first scans
through BackgroundWorkerList to see if it was a bgworker process. If not
39 matches
Mail list logo
