On 7/23/22 12:53, Zsolt Ero wrote:
> On 23. Jul 2022 at 18:43:57, David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> wrote:
>> On 7/23/22 12:39, Zsolt Ero wrote:
>>> > On 23. Jul 2022 at 15:20:32, David Steele <david@pgmasters.net
>>> <mailto:david@pgmasters.net>
>>> > <mailto:david@pgmasters.net <mailto:david@pgmasters.net>>> wrote:
>>> > Zsolt, can you add --log-level-console=info to your archive_command so
>>> > we can see what parameters are being passed to pgbackrest?
>>>
>>> archive_command = 'pgbackrest --stanza=app --log-level-console=info
>>> archive-push %p'
>>>
>>> on the destination server (where the restore happens). There are no
>>> changes in the log, only 3 lines appear once everything is done. I've
>>> attached the log. Do I need to change this command on the source server?
>>
>> Oops, sorry, I meant the restore_command on the server where you do the
>> restore.
>>
>> You'll need to edit this in postgresql.auto.conf after the pgbackrest
>> restore but before starting PostgreSQL.
>
> I did that, attached the new log.
From this log it looks like pgBackRest is writing to RECOVERYXLOG as I
expected.
The error happens relatively rarely (18) compared to the number of WAL
segments fetched (1029). pgBackRest does not write the files in
question, e.g.
LOG: could not link file "pg_wal/000000010000015B0000002C" to
"pg_wal/000000010000015B000000F4": File exists
And the pg_wal directory started empty.
I ran one our standard stress tests on 12.11 (recovering 1592 WAL
segments) and I did not see the "could not link file" message.
Your system seems to be doing recovery pretty quickly. I wonder if there
is a race condition in WAL recycling?
One thing you could try is to set wal_recycle = false.
Regards,
-David
