On Mon, 2010-03-15 at 11:27 +0200, Nicos Panayides wrote:
> thanks for the suggestion. What kind of space savings should I expected
> from turning off full_page_writes?
Substantial, though you should measure it and see, since it is workload
dependent.
--
Simon Riggs www.2ndQuadrant
Hi Simon,
thanks for the suggestion. What kind of space savings should I expected
from turning off full_page_writes? The servers have battery-backed
write-caches for the disk controllers, so it should be safe to give this
a try. Does turning off full_page_writes have any other effect on the
da
On Fri, 2010-03-12 at 18:40 +0200, Nicos Panayides wrote:
> I am planning an off-site backup solution for a fairly busy
> (mostly-write) 8.3 database. The database is currently about 200GB in
> size. I though about using log shipping and cold standby since it's easy
> in terms of administration
Sorry for that.The bug was incorrect calculation of XNOOP record
size in GiST WAL when incremental log is created from the full backup.
Because the bug impact is so serious, I'm rebuilding the test
environment which is taking long. I'll report the cause of the bug
to hackers and bugs.
If G
Nicos Panayides wrote:
> The database generates about 3 PITR log files per minute. If my
> calculations are correct the sites need to be connected with a
> 7MBit connection and the logs will need about 68GB of storage per
> day!
I'd have put the minimum line speed at 8Mb/second, but I figure
Nicos Panayides wrote:
> Hi,
> I am planning an off-site backup solution for a fairly busy
> (mostly-write) 8.3 database. The database is currently about 200GB in
> size. I though about using log shipping and cold standby since it's easy
> in terms of administration and also offers point in time
Hi,
I am planning an off-site backup solution for a fairly busy
(mostly-write) 8.3 database. The database is currently about 200GB in
size. I though about using log shipping and cold standby since it's easy
in terms of administration and also offers point in time recovery.
The database genera