Re: stopgap fix for signal handling during restore_command

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: stopgap fix for signal handling during restore_command
Date: 2023-02-24 01:15:36
Message-ID: CA+hUKGLJuRBN=ZmaWK1CsHsCUq_6sHkE4LjKJPt=EMS_NQszvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 24, 2023 at 1:25 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> ENOCOFFEE

Erm, I realised after sending that I'd accidentally sent a version
that uses fork() anyway, and now if I change it back to vfork() it
doesn't fail the way I wanted to demonstrate, at least on Linux. I
don't have time or desire to dig into how Linux vfork() really works
so I'll leave it at that... but the patch as posted does seem to be a
useful tool for understanding this failure... please just ignore the
confused comments about fork() vs vfork() therein.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2023-02-24 01:51:16 Re: Add LZ4 compression in pg_dump
Previous Message Justin Pryzby 2023-02-24 01:07:16 Re: pgsql: Refactor to add pg_strcoll(), pg_strxfrm(), and variants.