sergey grinko

Параметр восстановления: `--recovery-target-time` на сейчас: `pg_probackup-13 2.4.15` поддерживает указание с точностью только до секунд. А вот параметр самого postgres: `recovery_target_time` поддерживает до микросекунд. Я понимаю, что наверное не просто это...

Yes, it's very helpful. I always wanted to know that I have all the WALs in place and there are no gaps in them.

Включил режим DEBUG и вот что там происходит: ``` [DEBUG] 2022-07-29 19:10:41,969 - PGSQL-(host=localhost db=mamonsu user=mamonsu port=5432) - Run: "SELECT sum(shared_blks_read+local_blks_read+temp_blks_read)*8*1024, sum(shared_blks_written+local_blks_written+temp_blks_written)*8*1024,sum(shared_blks_dirtied+local_blks_dirtied)*8*1024, sum(blk_read_time)/float4(100), sum(blk_write_time)/float4(100), sum(total_exec_time+total_plan_time-blk_read_time-blk_write_time)/float4(100), sum(wal_bytes), sum(wal_records), sum(wal_fpi) FROM public.pg_stat_statements;"...

Благодарю. Буду смотреть.

Всё хорошо, Спасибо

Прошу включить эту доработку в версию 3.1.0

Как скоро можно ожидать применения моих идей в развитии плагина контроля за бэкапами?

Как скоро можно ожидать применения моих идей в развитии плагина контроля за бэкапами? Может есть какие-то вопросы у уважаемых разработчиков?

предлагаю рассмотреть возможность реализации - рефакторинга объектов. описанная ситуация подчасть рефакторинга. Начните с малого и постепенно давайте наращивать функциональность

Будет здорово иметь настройку для этого... Вообще-то было бы здорово иметь отдельный tree-view в котором мы бы видели всё так как в pgadmin. Это поможет также и легко получить нужный...