Hi,
I'm running PostgreSQL 8.3. Suppose I have master server A shipping logs
to backup server B. At some time in the past, I did a full backup from A
to B, and now B is running in recovery mode, happily consuming WALs.
Q1. If I stop and restart master server A gracefully, do I need to do
anyth
On Oct 13, 2009, at 1:17 PM, David F. Skoll wrote:
Hi,
I'm running PostgreSQL 8.3. Suppose I have master server A shipping
logs
to backup server B. At some time in the past, I did a full backup
from A
to B, and now B is running in recovery mode, happily consuming WALs.
I'm running 8.4,
"Thorne, Francis" wrote:
> I plan to place the database files on one RAID 10 partition and the
> logs on another partition either RAID 10 or RAID 1. At the moment
> though I'm struggling to size the partition of the log file. Is
> there a recommendation to how I could go about sizing this
> pa
On Tue, 2009-10-13 at 13:17 -0400, David F. Skoll wrote:
> Q2. If I stop and restart backup server B while master server A continues
> to run, will B continue eating WALs from where it left off? Or do we need
> another full backup? (We'll assume WAL shipping continues successfully during
> the
A quick question for you on this note, since you seem to actually be
doing
it.
In the case he suggested below, does B delete the WAL files once
consumed,
do I do that with an external monitor, or do they stay there forever
until I
run out of space?
The slave/standby server deletes the
Insufficient coffee:
My environment is a little strange (at least I never read about one
set up like this before I built it) and has some associated oddities
in the old segment cleanup process - All of my slaves mount an
archive partition on the master (read-only) and every log file is
"p
Assuming that autovacuum is off in 8,2 and upwards versions, would I
still have to do a database-wide vacuumdb OR would vacuuming
individual tables that are permanent be sufficient to take care of XID
wraparound?
2009/8/11 Alvaro Herrera :
> Anj Adu escribió:
>> Reason we dont turn on autovacuum
Anj Adu writes:
> Assuming that autovacuum is off in 8,2 and upwards versions, would I
> still have to do a database-wide vacuumdb OR would vacuuming
> individual tables that are permanent be sufficient to take care of XID
> wraparound?
In recent releases it is not possible to turn off autovacuu
We have a few 8.1 installations where the vacuumdb -a command takes
2-3 days to run ..(with a vacuum delay of 10ms)...autovac does not
work for us as we have tables that get constantly dropped due to
partitioning.(autovac would never finish given the size of our
database and the fact that we have s
Anj Adu escribió:
> We have a few 8.1 installations where the vacuumdb -a command takes
> 2-3 days to run ..(with a vacuum delay of 10ms)...autovac does not
> work for us as we have tables that get constantly dropped due to
> partitioning.(autovac would never finish given the size of our
> database
I am running Postgres 8.1.9 on an 8 core Xeon 5430 box that is showing
single digit CPU and IO utilization. the database size is 820G .
Vacuum_cost_delay=0 and maintenance_mem = 900M
Is there an option to vacuumdb or a way to make it run parallel threads.
--
Sent via pgsql-admin mailing list (pg
On Tue, Oct 13, 2009 at 7:29 PM, Anj Adu wrote:
> I am running Postgres 8.1.9 on an 8 core Xeon 5430 box that is showing
> single digit CPU and IO utilization. the database size is 820G .
> Vacuum_cost_delay=0 and maintenance_mem = 900M
>
> Is there an option to vacuumdb or a way to make it run pa
12 matches
Mail list logo
