wal-depth option is not taken on wal archive status.

[halvaborsch]

probackup@backup1:~$ pg_probackup-9.6 version
pg_probackup-9.6 2.4.9 (PostgreSQL 9.6.20)

Собираем 3 бэкапа.

probackup@backup1:~$ pg_probackup-9.6 show --instance=main
=========================================================================================================================================
 Instance  Version  ID      Recovery Time           Mode  WAL Mode  TLI      Time  Data    WAL  Zratio  Start LSN    Stop LSN     Status
=========================================================================================================================================
 main      9.6      QO8RU1  2021-02-09 10:19:15+07  FULL  ARCHIVE   143/0   2m:4s  40MB   16MB    6.83  39/39000028  39/3A0065B8  OK
 main      9.6      QO8RP1  2021-02-09 10:15:17+07  FULL  ARCHIVE   143/0   1m:7s  32MB  128MB    6.51  39/28000290  39/30A3EAA0  OK
 main      9.6      QO8R2K  2021-02-09 10:02:16+07  FULL  ARCHIVE   143/0  1m:33s  39MB  128MB    6.98  39/1D000028  39/25A3B470  OK

probackup@backup1:~$ pg_probackup-9.6 show --instance=main --archive
ARCHIVE INSTANCE 'main'
===============================================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno                 Max Segno                 N segments  Size  Zratio  N backups  Status
===============================================================================================================================
 143  142         38/88000098  0000008F000000390000001D  0000008F000000390000003A  30          21MB  23.38   3          OK

При wal-depth = 2 проводим чистку wal-сегментов и получаем архив в статусе DEGRADED.

probackup@backup1:~$ grep 'wal-depth\|retention' pg_probackup.conf
wal-depth = 2
retention-redundancy = 2
retention-window = 0

probackup@backup1:~$ pg_probackup-9.6 delete --instance=main --delete-wal
INFO: On timeline 143 WAL segments between 0000008F000000390000001D and 0000008F0000003900000028 will be removed
INFO: Logical WAL size to remove on timeline 143 : 176MB
INFO: Resident WAL size to free on timeline 143 : 7082kB
INFO: There are no backups to merge by retention policy
INFO: There are no backups to delete by retention policy


probackup@backup1:~$ pg_probackup-9.6 show --instance=main --archive

ARCHIVE INSTANCE 'main'
=================================================================================================================================
 TLI  Parent TLI  Switchpoint  Min Segno                 Max Segno                 N segments  Size  Zratio  N backups  Status
=================================================================================================================================
 143  142         38/88000098  0000008F000000390000001D  0000008F000000390000003A  28          20MB  21.94   3          DEGRADED

probackup@backup1:~$ pg_probackup-9.6 delete --instance=main --delete-wal --format json
...
                "status": "DEGRADED",
                "lost-segments": [
                    {
                        "begin-segno": "0000008F0000003900000026",
                        "end-segno": "0000008F0000003900000027"
                    }   
                ]
...

Мне кажется, wal-depth должен учитываться при проверки целостности архива. Примеры из документации говорят об этом же.

[gsmolk]

Добрый день! Я правильно понимаю, что Вы предлагаете начинать считать Min Segno от 0000008F0000003900000029?

[halvaborsch]

Всё верно, я ожидаю, что если в конфигурации я решил что PITR мне необходим только в рамках двух последний копий следовательно и консистентность архива я ожидаю в этих же рамках.

Причем тут ошибка возникает только если я использую метод ARCHIVE, в нем мы специально оставляем wal необходимые чтобы восстановить копии создавая "дыры" за пределами wal-depth. Я уверен, для обеспечения мониторинга архива стоит это учитывать.

[gsmolk]

Мне не нравится, что мы в таком случае начинаем немного обманывать юзера, сообщая ему один Min Segno, хотя по факту в архиве он другой. Но, наверное, корректность должна уступить практичности в этом случае.