From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres FDW cost estimation options unrecognized in 9.3-beta1 |
Date: | 2014-02-03 20:50:09 |
Message-ID: | 52F00101.2040108@hogranch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 2/3/2014 4:59 AM, Rajni Baliyan wrote:
> Is there any way to automate the archive deletion process. Any script
> or command in HA setup using pgpool
please don't reply to an existing thread with a completely different
topic and subject matter. your message is threaded under messages
about foreign data wrappers and cost estimation.
WAL archiving and pgpool have nothing to do with each other.
postgres manages the pg_xlog deletion process itself. if you're
keeping an external WAL archive, then any such deletion depends entirely
on your requirements for the use of said archive. if you want to be
able to do 'point in time recovery' aka PITR, you need ALL WAL archives
since the last base backup. if the WAL archive is for streaming
replication to use to catch up after a service interruption, then
probably a day or two is all you need unless you envision longer
downtimes for the slave.
scripts for doing things like deleting old files are OS dependent. on a
(l)unix type system, its as simple as...
find /path/to/files -mtime +2 | xargs rm
will delete everything over 2 days old in that path.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2014-02-03 20:51:00 | Re: way to custom sort column by fixed strings, then by field's content |
Previous Message | Rob Sargent | 2014-02-03 20:39:39 | Re: way to custom sort column by fixed strings, then by field's content |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-03 21:38:42 | Re: pgsql: Document a few more regression test hazards. |
Previous Message | Marko Tiikkaja | 2014-02-03 20:48:31 | Re: plpgsql.warn_shadow |