Refactoring backend fork+exec code

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Refactoring backend fork+exec code
Date: 2023-06-18 11:22:33
Message-ID: 7a59b073-5b5b-151e-7ed3-8b01ff7ce9ef@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 abstraction. I started doing this to help with implementing
multi-threading, but it doesn't introduce anything thread-related yet
and I think this improves readability anyway.

This is still work-inprogress, especially the last, big, patch in the
patch set. Mainly, I need to clean up the comments in the new
launch_backend.c file. But the other patches are in pretty good shape,
and if you ignore launch_backend.c, you can see the effect on the other
source files.

With these patches, there is a new function for launching a postmaster
child process:

pid_t postmaster_child_launch(PostmasterChildType child_type, char
*startup_data, size_t startup_data_len, ClientSocket *client_sock);

This function hides the differences between EXEC_BACKEND and
!EXEC_BACKEND cases.

In 'startup_data', the caller can pass a blob of data to the child
process, with different meaning for different kinds of child processes.
For a backend process, for example, it's used to pass the CAC_state,
which indicates whether the backend accepts the connection or just sends
"too many clients" error. And for background workers, it's used to pass
the BackgroundWorker struct. The startup data is passed to the child
process in the

ClientSocket is a new struct holds a socket FD, and the local and remote
address info. Before this patch set, postmaster initializes the Port
structs but only fills in those fields in it. With this patch set, we
have a new ClientSocket struct just for those fields, which makes it
more clear which fields are initialized where.

I haven't done much testing yet, and no testing at all on Windows, so
that's probably still broken.

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

Attachment Content-Type Size
0001-Allocate-Backend-structs-in-PostmasterContext.patch text/x-patch 4.9 KB
0002-Pass-background-worker-entry-in-the-parameter-file.patch text/x-patch 5.5 KB
0003-Refactor-CreateSharedMemoryAndSemaphores.patch text/x-patch 9.1 KB
0004-Use-FD_CLOEXEC-on-ListenSockets.patch text/x-patch 3.0 KB
0005-Move-too-many-clients-already-et-al.-checks-from-Pro.patch text/x-patch 3.6 KB
0006-Pass-CAC-as-argument-to-backend-process.patch text/x-patch 5.3 KB
0007-Remove-ConnCreate-and-ConnFree-and-allocate-Port-in-.patch text/x-patch 2.8 KB
0008-Introduce-ClientSocket-rename-some-funcs.patch text/x-patch 25.2 KB
0009-Refactor-postmaster-child-process-launching.patch text/x-patch 136.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2023-06-18 13:23:22 Re: Deleting prepared statements from libpq.
Previous Message Jelte Fennema 2023-06-18 11:03:57 Re: Deleting prepared statements from libpq.