Re: BUG #19032: In restore_command %f parameter does not support WAL partial files.

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>

To: wszenajch@gmail.com, pgsql-bugs@lists.postgresql.org

Date: 2025-08-27T00:48:14Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

oauth: Explicitly depend on -pthread
- 85b380162cd6 19 (unreleased) cited

On Tue, Aug 26, 2025 at 5:10 PM PG Bug reporting form <
noreply@postgresql.org> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      19032
> Logged by:          Wojciech Szenajch
> Email address:      wszenajch@gmail.com
> PostgreSQL version: 17.6
> Operating system:   Ubuntu 24.04.03 LTS
> Description:
>
> Using restore_command = 'cp /tmp/receivewal/%f %p' does not use WAL partial
> file during backup restore process.
>

While this seems un-documented in the user-facing documentation the source
code makes it clear this is intended behavior.  If your
point-in-time-recovery flow requires the use of these files you will need
to manually manipulate them.

https://github.com/postgres/postgres/blob/85b380162cd6c66752d1dd020a2d9700da0903c9/src/backend/access/transam/xlog.c#L5347

(link to article about a custom archiving process relying on pg_receivewal)

It seems unfortunate that the pg_receivewal creates files with ".partial"
extensions that are semantically different from what the core system
".partial" files are.  But if your archive process is custom (i.e., uses
something other than archive_command) it seems reasonable that any
restore_command you need to create would also be something custom.  Going
by the documentation for only half of the process is going to lead to these
kinds of inconsistent results.

David J.