Am 30.06.2025 um 21:45 schrieb Ron Johnson:
Using PgBackRest might be more convenient, since it handles everything
you need, is multithreaded, never removes too many wal files,
compresses files if you want and also encrypts them if you want.
I agree, with pgBackRest it's basically: pgbackre
## Franklin Anderson de Oliveira Souza (frankli...@gmail.com):
> LOG: database system was shut down at 2025-06-30 12:15:28 -04
> cp: cannot stat '/dados/temp/wals/0002.history': No such file or directory
> -
>
>
> The restore_command requires the .history file but it does not
On 6/30/25 12:35, Franklin Anderson de Oliveira Souza wrote:
I'm trying to simulate a PITR in postgresql 16 with the following steps:
-
LOG: starting PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc
(GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
LOG: listening on IPv6
Using PgBackRest might be more convenient, since it handles everything you
need, is multithreaded, never removes too many wal files, compresses files
if you want and also encrypts them if you want.
(In 2025, I also leave pg_wal on the same mount point as data/. Disk space
is plentiful and it's ju
I'm trying to simulate a PITR in postgresql 16 with the following steps:
directorys:
/data/primary
/data/base
/data/wals
/data/csv
1- Create cluster to primary postgresql:
/usr/pgsql-16/bin/initd -D /data/primary
2- Start Cluster ( port)
/usr/pgsql-16/bin/pg_ctl -D /data/primary start
3- Cr
Postgres version: PostgreSQL 17.5 on x86_64-pc-linux-gnu, compiled by
Debian clang version 12.0.1, 64-bit
Postgres hosting: Google Cloud Platform, Cloud SQL
Postgres CPU: 40 vCPU
Postgres Memory: 200 GB
Postgres setup: 1 primary with 1 read-replica (hot_standby_feedback flag is
on)
Issue:
We