After commit 7389aad6, I think commit 8acd8f86's linker changes (+
meson.build's equivalent) must now be redundant?
On Wed, Aug 31, 2022 at 1:34 AM Thomas Munro wrote:
> On Wed, Aug 31, 2022 at 12:26 AM Robert Haas wrote:
> > On Tue, Aug 30, 2022 at 8:17 AM Thomas Munro wrote:
> > > FWIW I suspect FreeBSD can't break like this in a program linked with
> > > libthr, because it has a scheme for deferring signal
Hi,
On 2022-08-30 14:32:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-30 14:07:41 -0400, Tom Lane wrote:
> >> Do we want to install this just for NetBSD, or more widely?
> >> I think we'd better back-patch it for NetBSD, so I'm inclined
> >> to be conservative about the change.
Andres Freund writes:
> On 2022-08-30 14:07:41 -0400, Tom Lane wrote:
>> Do we want to install this just for NetBSD, or more widely?
>> I think we'd better back-patch it for NetBSD, so I'm inclined
>> to be conservative about the change.
> It's likely a good idea to enable it everywhere applicabl
Hi,
On 2022-08-30 14:07:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-30 13:24:39 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Perhaps it'd be saner to default to building with -Wl,-z,now? That should
> >>> fix
> >>> the problem too, right (and if we combine it wit
Andres Freund writes:
> On 2022-08-30 13:24:39 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Perhaps it'd be saner to default to building with -Wl,-z,now? That should
>>> fix
>>> the problem too, right (and if we combine it with relro, it'd be a security
>>> improvement to boot).
>> Hm.
Hi,
On 2022-08-30 13:24:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Perhaps it'd be saner to default to building with -Wl,-z,now? That should
> > fix
> > the problem too, right (and if we combine it with relro, it'd be a security
> > improvement to boot).
>
> Hm. Not sure if that wor
Andres Freund writes:
> On 2022-08-29 15:43:55 -0400, Tom Lane wrote:
>> The attached patch seems to fix the problem, by forcing resolution of
>> the PLT link before we unblock signals. It depends on the assumption
>> that another select() call appearing within postmaster.c will share
>> the same
Hi,
On 2022-08-29 15:43:55 -0400, Tom Lane wrote:
> Buildfarm member mamba (NetBSD-current on prairiedog's former hardware)
> has failed repeatedly since I set it up. I have now run the cause of
> that to ground [1], and here's what's happening: if the postmaster
> receives a signal just before i
On Wed, Aug 31, 2022 at 12:26 AM Robert Haas wrote:
> On Tue, Aug 30, 2022 at 8:17 AM Thomas Munro wrote:
> > FWIW I suspect FreeBSD can't break like this in a program linked with
> > libthr, because it has a scheme for deferring signals while the
> > runtime linker holds locks. _rtld_bind calls
On Tue, Aug 30, 2022 at 8:17 AM Thomas Munro wrote:
> FWIW I suspect FreeBSD can't break like this in a program linked with
> libthr, because it has a scheme for deferring signals while the
> runtime linker holds locks. _rtld_bind calls _thr_rtld_rlock_acquire,
> which uses the THR_CRITICAL_ENTER
On Tue, Aug 30, 2022 at 7:44 AM Tom Lane wrote:
> Buildfarm member mamba (NetBSD-current on prairiedog's former hardware)
> has failed repeatedly since I set it up. I have now run the cause of
> that to ground [1], and here's what's happening: if the postmaster
> receives a signal just before it
On Mon, Aug 29, 2022 at 03:43:55PM -0400, Tom Lane wrote:
> I'd originally intended to make this code "#ifdef __NetBSD__",
> but on looking into the FreeBSD sources I find much the same locking
> logic in their dynamic loader, and now I'm wondering if such behavior
> isn't pretty standard.
I doubt
13 matches
Mail list logo
