Hi Craig,
Anyway, this OS is guess OS in vmware (vsphere).
Thank for your response and help.
On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>
>
> Can you get stacks please?
>
> Use -g
>
# Events: 2K cpu-clock
#
# Overhead Command Shared ObjectSymbol
# ...
Hi all,
I've an environment 9.4 + bdr:
PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.7.2-5) 4.7.2, 64-bit
kernel version:
3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux
This is consolidation databases, in this machine there are around 250+ wal
sender processes.
, Sep 15, 2017 at 11:14 AM, Craig Ringer
wrote:
> On 15 September 2017 at 11:46, milist ujang
> wrote:
>
>> Hi Craig,
>>
>> Thanks again for pointing to inactive replication slot.
>> After inactive replication slot been dropped, the relfrozenxid now moving.
>>
Hi Craig,
Thanks again for pointing to inactive replication slot.
After inactive replication slot been dropped, the relfrozenxid now moving.
I wonder if replication identifier will have some issue if left
un-chained? since at other side there are inactive replication identifier.
On Fri, Sep 1
HI list,
I have a database with bdr environment which keep alerting these messages
in log file:
HINT: Close open transactions soon to avoid wraparound problems.
WARNING: oldest xmin is far in the past
Querying pg_stat_activity where state='active';
datname | template1
query
Hi all,
Based on the docs and look at the processes, it seems 1 wal sender on each
node per group.
If there is scenario of consolidating many databases (say hundreds) into 1
database (in this central cluster there are hundreds wal sender), what is
the limit number of groups?
I wonder if anyone h
Hi Craig,
On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer wrote:
>
> You could drop and re-create the replication slot, I guess. But your nodes
> would be hopelessly out of sync and need manual resync (with data
> replication disabled) of one node vs another.
>
Thanks for pointing to replication s
Hi Craig
On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer wrote:
>
>
> BDR can, see bdr.skip_changes_upto .
>
> Unluckily my bdr is 0.9.3
> But PostgreSQL's logical decoding requires a contiguous WAL stream to
> maintain a valid catalog_xmin and restart_lsn, so it'll still fail to
> advance. So you
Hi all,
due to space issue and high volume transaction, some wal segments removed
from pg_xlog on bdr environment.
warning log at node1 saying "requested WAL segment . has already been
removed" following Connection reset by peer.
log at node2 :
Sending replication command: START_REPLICATION
