Re: Non-blocking archiver process

From: Noah Misch <noah(at)leadboat(dot)com>
To: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Non-blocking archiver process
Date: 2025-07-05 03:01:07
Message-ID: 20250705030107.f4.nmisch@google.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 04, 2025 at 08:46:08AM +0200, Ronan Dunklau wrote:
> We've noticed a behavior that seems surprising to us.
> Since DROP DATABASE now waits for a ProcSignalBarrier, it can hang up
> indefinitely if the archive_command hangs.
>
> The reason for this is that the builtin archive module doesn't process any
> interrupts while the archiving command is running, as it's run with a system()
> call, blocking undefintely.
>
> Before rushing on to implement a non-blocking archive library (perhaps using
> popen or posix_spawn, while keeping other systems in mind), what unintended
> consequences would it have to actually run the archive_command in a non-
> blocking way, and checking interrupts while it runs ?

I can't think of any unintended consequences. I think we just missed this
when adding the first use of ProcSignalBarrier (v15). Making this easier to
miss, archiver spent most of its history not connecting to shared memory. Its
shared memory connection appeared in v14.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-07-05 03:35:28 Re: array_random
Previous Message Tom Lane 2025-07-05 02:24:38 Re: A assert failure when initdb with track_commit_timestamp=on