I pushed the libpq changes. I'll leave the pipe2 and accept4 changes
on ice for now, maybe for a later cycle (unlike the committed patches,
they don't currently fix a known problem, they just avoid some
syscalls that are already fairly rare). For the libpq change, the
build farm seems happy so fa
On Thu, Mar 2, 2023 at 9:57 AM Thomas Munro wrote:
> On Thu, Mar 2, 2023 at 9:49 AM Gregory Stark (as CFM)
> wrote:
> > On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
> > > Done like that in this version. This is the version I'm thinking of
> > > committing, unless someone wants to argue for
On Thu, Mar 2, 2023 at 9:49 AM Gregory Stark (as CFM)
wrote:
> On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
> >
> > Done like that in this version. This is the version I'm thinking of
> > committing, unless someone wants to argue for another level.
>
> FWIW the cfbot doesn't understand this
On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
>
> Done like that in this version. This is the version I'm thinking of
> committing, unless someone wants to argue for another level.
FWIW the cfbot doesn't understand this patch series. I'm not sure why
but it's only trying to apply the first (
Something bothered me about the previous versions: Which layer should
add O_CLOEXEC, given that we have md.c -> PathNameOpenXXX() ->
BasicOpenFile() -> open()? Previously I had md.c adding it, but on
reflection, it makes no sense to open a "File" (virtual file
descriptor) that is *not* O_CLOEXEC.
I had missed one: the "watch" end of the postmaster pipe also needs FD_CLOEXEC.
From 36f8ed2406307f8b1578ae85510c5a07718e1ea8 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon, 20 Feb 2023 23:26:36 +1300
Subject: [PATCH v3 1/3] Don't leak descriptors into subprograms.
Open data and WAL files
On Mon, Feb 6, 2023 at 3:29 AM Andres Freund wrote:
> On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> wrote:
> >Are there any more descriptors we need to think about?
>
> Postmaster's listen sockets? Saves a bunch of syscalls, at least.
Assuming you mean accepted sockets, yeah, I see h
Hi,
On 2023-02-05 11:06:13 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> > wrote:
> >> Are there any more descriptors we need to think about?
>
> > Postmaster's listen sockets?
>
> I wonder whether O_CLOEXEC on that would be inheri
Andres Freund writes:
> On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
> wrote:
>> Are there any more descriptors we need to think about?
> Postmaster's listen sockets?
I wonder whether O_CLOEXEC on that would be inherited by the
client-communication sockets, though. That's fine ... u
Hi,
Unsurprisingly I'm in favor of this.
On February 5, 2023 1:00:50 AM GMT+01:00, Thomas Munro
wrote:
>Are there any more descriptors we need to think about?
Postmaster's listen sockets? Saves a bunch of syscalls, at least. Logging
collector pipe write end, in backends?
Greetings,
Andres
Thomas Munro writes:
> On Sun, Feb 5, 2023 at 1:00 PM Thomas Munro wrote:
>> SUSv3 (POSIX 2008)
> Oh, oops, 2008 actually corresponds to SUSv4. Hmm.
Worst case, if we come across some allegedly-supported platform without
O_CLOEXEC, we #define that to zero. Said platform is no worse off
than i
On Sun, Feb 5, 2023 at 1:00 PM Thomas Munro wrote:
> SUSv3 (POSIX 2008)
Oh, oops, 2008 actually corresponds to SUSv4. Hmm.
While investigating code paths that use system() and popen() and
trying to write latch-multiplexing replacements, which I'll write
about separately, leaks of $SUBJECT became obvious. On a FreeBSD box,
you can see the sockets, pipes and data and WAL files that the
subprocess inherits:
create tab
13 matches
Mail list logo
