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.
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 |