On 18/05/2024 08:24, Thomas Munro wrote:
Nitpicking from UBSan with EXEC_BACKEND on Linux (line numbers may be
a bit off, from a branch of mine):
../src/backend/postmaster/launch_backend.c:772:2: runtime error: null
pointer passed as argument 2, which is declared to never be null
==13303==Using
While looking into [0], I noticed that main() still only checks for the
--fork prefix, but IIUC commit aafc05d removed all --fork* options except
for --forkchild. I've attached a patch to strengthen the check in main().
This is definitely just a nitpick.
[0]
https://postgr.es/m/CAKAnmmJkZtZAiSry
On Mon, Mar 18, 2024 at 10:41 PM Heikki Linnakangas wrote:
> Committed, with some final cosmetic cleanups. Thanks everyone!
Nitpicking from UBSan with EXEC_BACKEND on Linux (line numbers may be
a bit off, from a branch of mine):
../src/backend/postmaster/launch_backend.c:772:2: runtime error: nu
On 28.04.2024 22:36, Heikki Linnakangas wrote:
Peter E noticed and Michael fixed them in commit 768ceeeaa1 already.
Didn't check that is already fixed in the current master. Sorry!
Thanks for pointing this out!
With the best wishes,
--
Anton A. Melnikov
Postgres Professional: http://www.pos
On 27/04/2024 11:27, Anton A. Melnikov wrote:
Hello!
Maybe add PGDLLIMPORT to
extern bool LoadedSSL;
and
extern struct ClientSocket *MyClientSocket;
definitions in the src/include/postmaster/postmaster.h ?
Peter E noticed and Michael fixed them in commit 768ceeeaa1 already.
--
Heikki Linnakang
Hello!
Maybe add PGDLLIMPORT to
extern bool LoadedSSL;
and
extern struct ClientSocket *MyClientSocket;
definitions in the src/include/postmaster/postmaster.h ?
With the best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, 20 Mar 2024 at 08:16, Heikki Linnakangas wrote:
> Yeah, it's not a very valuable assertion. Removed, thanks!
How about we add it as a static assert instead of removing it, like we
have for many other similar arrays.
v1-0001-Add-child_process_kinds-static-assert.patch
Description: Binary
On 20/03/2024 07:37, Tom Lane wrote:
A couple of buildfarm animals don't like these tests:
Assert(child_type >= 0 && child_type < lengthof(child_process_kinds));
for example
ayu | 2024-03-19 13:08:05 | launch_backend.c:211:39: warning:
comparison of constant 16 with expres
Heikki Linnakangas writes:
> Committed, with some final cosmetic cleanups. Thanks everyone!
A couple of buildfarm animals don't like these tests:
Assert(child_type >= 0 && child_type < lengthof(child_process_kinds));
for example
ayu | 2024-03-19 13:08:05 | launch_backend.c:2
On 13/03/2024 09:30, Heikki Linnakangas wrote:
Attached is a new version of the remaining patches.
Committed, with some final cosmetic cleanups. Thanks everyone!
--
Heikki Linnakangas
Neon (https://neon.tech)
On Mon Mar 4, 2024 at 3:05 AM CST, Heikki Linnakangas wrote:
I've now completed many of the side-quests, here are the patches that
remain.
The first three patches form a logical unit. They move the
initialization of the Port struct from postmaster to the backend
process. Currently, that work
On 05/03/2024 11:44, Richard Guo wrote:
I noticed that there are still three places in backend_status.c where
pgstat_get_beentry_by_backend_id() is referenced. I think we should
replace them with pgstat_get_beentry_by_proc_number().
Fixed, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech
On Mon, Mar 4, 2024 at 1:40 AM Heikki Linnakangas wrote:
> On 22/02/2024 02:37, Heikki Linnakangas wrote:
> > Here's another patch version that does that. Yeah, I agree it's nicer in
> > the end.
> >
> > I'm pretty happy with this now. I'll read through these patches myself
> > again after sleepi
On 22/02/2024 02:37, Heikki Linnakangas wrote:
On 15/02/2024 07:09, Robert Haas wrote:
On Thu, Feb 15, 2024 at 3:07 AM Andres Freund wrote:
I think the last remaining question here is about the 0- vs 1-based indexing
of BackendIds. Is it a good idea to switch to 0-based indexing? And if we do
On Thu, Feb 15, 2024 at 3:07 AM Andres Freund wrote:
> > I think the last remaining question here is about the 0- vs 1-based indexing
> > of BackendIds. Is it a good idea to switch to 0-based indexing? And if we do
> > it, should we reserve PGPROC 0. I'm on the fence on this one.
>
> I lean toward
Hi,
On 2024-02-08 13:19:53 +0200, Heikki Linnakangas wrote:
> > > - /*
> > > - * Assign the ProcSignalSlot for an auxiliary process. Since it doesn't
> > > - * have a BackendId, the slot is statically allocated based on the
> > > - * auxiliary process type (MyAuxProcType). Backends use slots
On 07/02/2024 20:25, Andres Freund wrote:
On 2024-01-30 02:08:36 +0200, Heikki Linnakangas wrote:
From 54f22231bb2540fc5957c14005956161e6fc9dac Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Wed, 24 Jan 2024 23:15:55 +0200
Subject: [PATCH v8 1/5] Remove superfluous 'pgprocno' field fr
Hi,
On 2024-01-30 02:08:36 +0200, Heikki Linnakangas wrote:
> I spent some more time on the 'lastBackend' optimization in sinvaladt.c. I
> realized that it became very useless with these patches, because aux
> processes are allocated pgprocno's after all the slots for regular backends.
> There are
On 30/01/2024 02:08, Heikki Linnakangas wrote:
On 29/01/2024 17:54, reid.thomp...@crunchydata.com wrote:
On Thu, 2024-01-25 at 01:51 +0200, Heikki Linnakangas wrote:
And here we go. BackendID is now a 1-based index directly into the
PGPROC array.
Would it be worthwhile to also note in this c
On 29/01/2024 17:54, reid.thomp...@crunchydata.com wrote:
On Thu, 2024-01-25 at 01:51 +0200, Heikki Linnakangas wrote:
And here we go. BackendID is now a 1-based index directly into the
PGPROC array.
Would it be worthwhile to also note in this comment FIRST_AUX_PROC's
and IsAuxProcess()'s dep
On Thu, 2024-01-25 at 01:51 +0200, Heikki Linnakangas wrote:
>
> And here we go. BackendID is now a 1-based index directly into the
> PGPROC array.
>
Would it be worthwhile to also note in this comment FIRST_AUX_PROC's
and IsAuxProcess()'s dependency on B_ARCHIVER and it's location in the
enum
On 23/01/2024 21:50, Andres Freund wrote:
On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote:
On 22/01/2024 23:07, Andres Freund wrote:
diff --git a/src/backend/utils/activity/backend_status.c
b/src/backend/utils/activity/backend_status.c
index 1a1050c8da1..92f24db4e18 100644
--- a/src/bac
Hi,
On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote:
> On 22/01/2024 23:07, Andres Freund wrote:
> > > diff --git a/src/backend/utils/activity/backend_status.c
> > > b/src/backend/utils/activity/backend_status.c
> > > index 1a1050c8da1..92f24db4e18 100644
> > > --- a/src/backend/utils/acti
On 22/01/2024 23:07, Andres Freund wrote:
On 2024-01-10 14:35:52 +0200, Heikki Linnakangas wrote:
@@ -5344,31 +5344,31 @@ StartChildProcess(AuxProcType type)
errno = save_errno;
switch (type)
{
- case StartupProcess:
+
Hi,
On 2024-01-10 14:35:52 +0200, Heikki Linnakangas wrote:
> Here's a patch that gets rid of AuxProcType. It's independent of the other
> patches in this thread; if this is committed, I'll rebase the rest of the
> patches over this and get rid of the new PMC_* enum.
>
> Three patches, actually.
On 08/12/2023 14:33, Heikki Linnakangas wrote:
+ [PMC_AV_LAUNCHER] = {"autovacuum launcher", AutoVacLauncherMain, true},
+ [PMC_AV_WORKER] = {"autovacuum worker", AutoVacWorkerMain, true},
+ [PMC_BGWORKER] = {"bgworker", BackgroundWorkerMain, true},
+ [PMC_SYSLOGGER] = {"s
On 02/12/2023 05:00, Alexander Lakhin wrote:
What bothered me additionally, is an error detected after server start. I
couldn't see it without the patches applied. I mean, on HEAD I now see
`make check` passing, but with the patches it fails:
...
# parallel group (20 tests): interval date numero
Hello Heikki,
01.12.2023 23:44, Heikki Linnakangas wrote:
With memset(param, 0, sizeof(*param)); added at the beginning of
save_backend_variables(), server starts successfully, but then
`make check` fails with other Valgrind error.
That's actually a pre-existing issue, I'm seeing that even o
"Tristan Partin" writes:
> On Fri Dec 1, 2023 at 2:44 PM CST, Heikki Linnakangas wrote:
>> Committed a fix with memset(). I'm not sure what our policy with
>> backpatching this kind of issues is. This goes back to all supported
>> versions, but given the lack of complaints, I chose to not backpa
On Fri Dec 1, 2023 at 2:44 PM CST, Heikki Linnakangas wrote:
On 01/12/2023 16:00, Alexander Lakhin wrote:
> Maybe you could look at issues with running `make check` under Valgrind
> when server built with CPPFLAGS="-DUSE_VALGRIND -DEXEC_BACKEND":
> # +++ regress check in src/test/regress +++
> #
On 01/12/2023 16:00, Alexander Lakhin wrote:
Maybe you could look at issues with running `make check` under Valgrind
when server built with CPPFLAGS="-DUSE_VALGRIND -DEXEC_BACKEND":
# +++ regress check in src/test/regress +++
# initializing database system by copying initdb template
# postmaster
On Fri Dec 1, 2023 at 6:10 AM CST, Heikki Linnakangas wrote:
On 30/11/2023 20:44, Tristan Partin wrote:
> Patches 1-3 seem committable as-is.
Thanks for the review! I'm focusing on patches 1-3 now, and will come
back to the rest after committing 1-3.
There was one test failure with EXEC_BACKE
Hello Heikki,
01.12.2023 15:10, Heikki Linnakangas wrote:
Attached is new version of these patches. For easier review, I made the new refactorings compared in a new commit
0003. I will squash that before pushing, but this makes it easier to see what changed.
Barring any new feedback or issues,
On 30/11/2023 20:44, Tristan Partin wrote:
Patches 1-3 seem committable as-is.
Thanks for the review! I'm focusing on patches 1-3 now, and will come
back to the rest after committing 1-3.
There was one test failure with EXEC_BACKEND from patch 2, in
'test_shm_mq'. In restore_backend_variabl
Hi,
On 2023-12-01 01:36:13 +0200, Heikki Linnakangas wrote:
> On 30/11/2023 22:26, Andres Freund wrote:
> > On 2023-11-30 01:36:25 +0200, Heikki Linnakangas wrote:
> > > From a96b6e92fdeaa947bf32774c425419b8f987b8e2 Mon Sep 17 00:00:00 2001
> > > From: Heikki Linnakangas
> > > Date: Thu, 30 Nov
On 30/11/2023 22:26, Andres Freund wrote:
On 2023-11-30 01:36:25 +0200, Heikki Linnakangas wrote:
From a96b6e92fdeaa947bf32774c425419b8f987b8e2 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Thu, 30 Nov 2023 00:01:25 +0200
Subject: [PATCH v3 1/7] Refactor CreateSharedMemoryAndSemaphor
On 30/11/2023 22:26, Andres Freund wrote:
Aside: Somewhat odd that InitAuxiliaryProcess() doesn't call
InitLWLockAccess().
Yeah that caught my eye too.
It seems to have been an oversight in commit 1c6821be31f. Before that,
in 9.4, the lwlock stats were printed for aux processes too, on shutdo
On Fri, Dec 1, 2023 at 9:31 AM Andres Freund wrote:
> On 2023-11-30 12:44:33 -0600, Tristan Partin wrote:
> > > +/*
> > > + * Set reference point for stack-depth checking. This might
> > > seem
> > > + * redundant in !EXEC_BACKEND builds; but it's not because the
> >
Hi,
On 2023-11-30 12:44:33 -0600, Tristan Partin wrote:
> > +/*
> > + * Set reference point for stack-depth checking. This might seem
> > + * redundant in !EXEC_BACKEND builds; but it's not because the
> > postmaster
> > + * launches its children from signal h
Hi,
On 2023-11-30 01:36:25 +0200, Heikki Linnakangas wrote:
> - patch 1 splits CreateSharedMemoryAndSemaphores into two functions:
> CreateSharedMemoryAndSemaphores is now only called at postmaster startup,
> and a new function called AttachSharedMemoryStructs() is called in backends
> in EXEC_BAC
On Wed Nov 29, 2023 at 5:36 PM CST, Heikki Linnakangas wrote:
On 11/10/2023 14:12, Heikki Linnakangas wrote:
Here's another rebased patch set. Compared to previous version, I did a
little more refactoring around CreateSharedMemoryAndSemaphores and
InitProcess:
- patch 1 splits CreateSharedMem
On Fri, Oct 06, 2023 at 10:27:22AM +0300, Heikki Linnakangas wrote:
> I did a quick test with syslogger enabled before committing, but didn't
> notice the segfault. I missed it because syslogger gets restarted and then
> it worked.
Thanks, Heikki.
--
Michael
signature.asc
Description: PGP signat
On 06/10/2023 09:50, Michael Paquier wrote:
On Fri, Oct 06, 2023 at 02:30:16PM +0900, Michael Paquier wrote:
Okay, the backtrace is not that useful. I'll see if I can get
something better, still it seems like this has broken the way the
syslogger closes these ports.
And here you go:
Program t
On Fri, Oct 06, 2023 at 02:30:16PM +0900, Michael Paquier wrote:
> Okay, the backtrace is not that useful. I'll see if I can get
> something better, still it seems like this has broken the way the
> syslogger closes these ports.
And here you go:
Program terminated with signal SIGSEGV, Segmentatio
On Thu, Oct 05, 2023 at 03:08:37PM +0300, Heikki Linnakangas wrote:
> This seems pretty uncontroversial, and I heard no objections, so I went
> ahead and committed that.
It looks like e29c4643951 is causing issues here. While doing
benchmarking on a cluster compiled with -O2, I got a crash:
LOG:
On 29/08/2023 09:58, Heikki Linnakangas wrote:
On 29/08/2023 09:21, Heikki Linnakangas wrote:
Thinking about this some more, the ListenSockets array is a bit silly
anyway. We fill the array starting from index 0, always append to the
end, and never remove entries from it. It would seem more
stra
On 29/08/2023 09:21, Heikki Linnakangas wrote:
Thinking about this some more, the ListenSockets array is a bit silly
anyway. We fill the array starting from index 0, always append to the
end, and never remove entries from it. It would seem more
straightforward to keep track of the used size of th
On 29/08/2023 01:28, Michael Paquier wrote:
In case you've not noticed:
https://www.postgresql.org/message-id/zovvuqe0rdj2s...@paquier.xyz
But it does not really matter now ;)
Ah sorry, missed that thread.
Yes, so it seems. Syslogger is started before the ListenSockets array is
initialized,
On Mon, Aug 28, 2023 at 11:52:15PM +0300, Heikki Linnakangas wrote:
> On 28/08/2023 18:55, Jeff Janes wrote:
>> Since this commit, I'm getting a lot (63 per restart) of messages:
>>
>> LOG: could not close client or listen socket: Bad file descriptor
>> All I have to do to get the message is tu
On 28/08/2023 18:55, Jeff Janes wrote:
Since this commit, I'm getting a lot (63 per restart) of messages:
LOG: could not close client or listen socket: Bad file descriptor
All I have to do to get the message is turn logging_collector = on and
restart.
The close failure condition existed be
On Thu, Aug 24, 2023 at 10:05 AM Heikki Linnakangas wrote:
> On 24/08/2023 15:48, Thomas Munro wrote:
> > LGTM. I vaguely recall thinking that it might be better to keep
> > EXEC_BACKEND and !EXEC_BACKEND working the same which might be why I
> > didn't try this one, but it looks fine with the c
On 24/08/2023 15:48, Thomas Munro wrote:
LGTM. I vaguely recall thinking that it might be better to keep
EXEC_BACKEND and !EXEC_BACKEND working the same which might be why I
didn't try this one, but it looks fine with the comment to explain, as
you have it. (It's a shame we can't use O_CLOFORK.
On Thu, Aug 24, 2023 at 11:41 PM Heikki Linnakangas wrote:
> On 11/07/2023 01:50, Andres Freund wrote:
> >> From: Heikki Linnakangas
> >> Date: Mon, 12 Jun 2023 16:33:20 +0300
> >> Subject: [PATCH 4/9] Use FD_CLOEXEC on ListenSockets
> >>
> >> We went through some effort to close them in the chil
Focusing on this one patch in this series:
On 11/07/2023 01:50, Andres Freund wrote:
From: Heikki Linnakangas
Date: Mon, 12 Jun 2023 16:33:20 +0300
Subject: [PATCH 4/9] Use FD_CLOEXEC on ListenSockets
We went through some effort to close them in the child process. Better to
not hand them down
Hi,
On 2023-06-18 14:22:33 +0300, Heikki Linnakangas wrote:
> I started to look at the code in postmaster.c related to launching child
> processes. I tried to reduce the difference between EXEC_BACKEND and
> !EXEC_BACKEND code paths, and put the code that needs to differ behind a
> better abstract
> From 1d89eec53c7fefa7a4a8c011c9f19e3df64dc436 Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas
> Date: Mon, 12 Jun 2023 16:33:20 +0300
> Subject: [PATCH 4/9] Use FD_CLOEXEC on ListenSockets
> @@ -831,7 +834,8 @@ StreamConnection(pgsocket server_fd, Port *port)
> void
> StreamClose(pgsocket
56 matches
Mail list logo
