Greetings,
* Rhhh Lin (ruanline...@hotmail.com) wrote:
> I would actually be an advocate for using a proper archive_command in order
> to facilitate a proper (Per the documentation) PITR and backup strategy.
Glad to hear it.
> However, a colleague had suggested such a creative approach (Possibl
On Tue, Oct 31, 2017 at 9:53 AM, Rhhh Lin wrote:
> I would actually be an advocate for using a proper archive_command in order
> to facilitate a proper (Per the documentation) PITR and backup strategy.
You should avoid using your own fancy archive command. There are
things that WAL-E for this pur
To: Rhhh Lin
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Backup strategy using 'wal_keep_segments'
Greetings,
* Rhhh Lin (ruanline...@hotmail.com) wrote:
> A colleague recently suggested that instead of implementing an
> 'archive_command' to push archivable WALs to
Greetings,
* Rhhh Lin (ruanline...@hotmail.com) wrote:
> A colleague recently suggested that instead of implementing an
> 'archive_command' to push archivable WALs to a secondary location (for
> further backup to tape for example), we could instead persist the WAL files
> in their current locat
] Backup strategy using 'wal_keep_segments'
On Mon, Oct 23, 2017 at 5:57 AM, Rhhh Lin wrote:
> Is this approach feasible? Assuming obviously, we have sufficient disk space
> to facilitate 1000 WAL files etc.
You expose yourself to race conditions with such methods if a
checkpoint has
On Mon, Oct 23, 2017 at 5:57 AM, Rhhh Lin wrote:
> Is this approach feasible? Assuming obviously, we have sufficient disk space
> to facilitate 1000 WAL files etc.
You expose yourself to race conditions with such methods if a
checkpoint has the bad idea to recycle past segments that your logic
is
Hi,
Version 9.4...
Per the PG docs, to facilitate continuous WAL archiving and PITR recovery...
"To enable WAL archiving, set the wal_level configuration parameter to archive
(or hot_standby), archive_mode to on, and specify the shell command to use in
the archive_command configuration paramet
