ple would be
two concurrent transactions that UPDATE completely different rows and
in so doing violate a UNIQUE constraint.
Thanks.
--Cliff Krumvieda
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
;t violate the constraint: will they be able to proceed in
parallel? Or will one wait for the other, because they both need to
update the shared index? I.e., does the mechanism work by waiting for
one index update to commit before permitting the next?
You don't give a lot of information, but try "sudo rm postmaster.pid" or
"sudo -u postgres rm postmaster.pid" if you are sure that postgres is not
running.
Cheers,
Cliff
On Tue, Feb 18, 2014 at 12:07 AM, Rob Goethals / SNP wrote:
> Hi,
>
>
>
> This is
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
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:
>
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
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
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:
> >>
I had not run these commands on the master as I was only doing sql updates
~1mil of them
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
10 matches
Mail list logo
