Can you not change your method of streaming replication. What is your
archive command, are you using rsync as you can control the bandwidth limit?
We use: archive_command = 'test ! -f
/opt/postgres/remote_pgsql/wal_archive/%f && rsync -az %p
/opt/postgres/remote_pgsql/wal_archive/%f'
According to
I had not run these commands on the master as I was only doing sql updates
~1mil of them
On 22 January 2013 16:43, Kevin Grittner wrote:
> [Please keep the list copied, and put your reply in-line instead
> of at the top.]
>
> Cliff de Carteret wrote:
> > On 22 January 2013 16:07, Kevin Grittner wrote:
> >
> >> Cliff de Carteret wrote:
> >>
llation to a
backups folder which gave me ~2G of space to start up again until I was
able to mount a new disk and move the pg_xlog to a separate partition using
a symbolic link.
On 22 January 2013 16:15, Adrian Klaver wrote:
> On 01/22/2013 07:57 AM, Cliff de Carteret wrote:
>
>> The
successfully for several years until the
recent database crash
On 22 January 2013 15:34, Adrian Klaver wrote:
> On 01/22/2013 06:59 AM, Cliff de Carteret wrote:
>
>> Hello, thanks for your response.
>>
>> The xlogs that are filling up are in the original data directory and
Hello, thanks for your response.
The xlogs that are filling up are in the original data directory and the
wal_keep_segments is commented out on my master and slave postgresql.conf
Cliff
On 22 January 2013 14:48, Adrian Klaver wrote:
> On 01/22/2013 03:12 AM, Cliff de Carteret wrote:
>
My database crashed a couple of days ago during an upgrade several seconds
after committing a large transaction to the database. Eventually we found
out that this was due to the disk being full as the transaction had created
several gigs of data. A day or so later the disk is full again and
Postgre
