Hi Vamsi,
We have been doing these steps to setup streaming replication
--Primay-Server
CREATE ROLE repl REPLICATION LOGIN PASSWORD 'your_password';
postgresql.conf
listen_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'copy %p \\path_to_archive\\%f'
max_wal_senders =
Hi Team,
we have upgraded postgresql version 11 to 14 on windows server 2016, post
upgrade we configured streaming replication. the data is not getting
replicated. but compared to version 11, 14 is very different in
configuring replication. Tried from documentation from postgres site. no
luck, Any
On Wed, Dec 1, 2021 at 5:56 PM Marcos Pegoraro wrote:
>
>> I have an issue with logical replication after Postgresql upgrade from
>> 13 to 14 (upgraded subscriber only using pg_upgrade_cluster -m link 13
>> main). After upgrade all subscriptions were disabled so I have enabled
>> them and replicat
I think there are some bugs in Posgresql logical replication upgrade.
Because dropping and recreating subscriptions with manual
synchronization has solved the problem for me. But it is not the
correct way, IMHO.
Sergey Belyashov
ср, 1 дек. 2021 г. в 15:26, Marcos Pegoraro :
>
>
>> I have an issue
> I have an issue with logical replication after Postgresql upgrade from
> 13 to 14 (upgraded subscriber only using pg_upgrade_cluster -m link 13
> main). After upgrade all subscriptions were disabled so I have enabled
> them and replication workers successfully started.
> pg_stat_subscription cont
I have an issue with logical replication after Postgresql upgrade from
13 to 14 (upgraded subscriber only using pg_upgrade_cluster -m link 13
main). After upgrade all subscriptions were disabled so I have enabled
them and replication workers successfully started.
pg_stat_subscription contains list
Hi Team,
Greetings! I have a doubt regarding Postgres replication. I am able to create
replication setup. But when the network is down for 60 seconds, the replication
was broken. Communication is broken between Master and slave. Slave is trying
to become master and it is not able to sync with m
hello Kyotaro,
thx for you feedback and clarification.
Le ven. 31 juil. 2020 à 02:13, Kyotaro Horiguchi
a écrit :
> Hi,
>
> At Thu, 30 Jul 2020 14:54:08 +0100, FOUTE K. Jaurès
> wrote in
> > Hi everyone,
> >
> > Situation:
> >
> >- A Master Database on the HQ
> >- i make a dump of th
Hi,
At Thu, 30 Jul 2020 14:54:08 +0100, FOUTE K. Jaurès
wrote in
> Hi everyone,
>
> Situation:
>
>- A Master Database on the HQ
>- i make a dump of the master database to the Subdivision Server
>- I create à Publication like: CREATE PUBLICATION
>iNOV_MasterData_Table_Pub FOR T
Hi everyone,
Situation:
- A Master Database on the HQ
- i make a dump of the master database to the Subdivision Server
- I create à Publication like: CREATE PUBLICATION
iNOV_MasterData_Table_Pub FOR TABLE M_Product; On the Master Database
- On the Subdivision Server, I create a Sub
My table has a primary key. In addition, this is an initial load issue where
the replication identity should not matter.
-Original Message-
From: Michael Lewis
To: Donzell White
Cc: pgsql-general
Sent: Tue, Jun 30, 2020 1:05 pm
Subject: Re: Logical Replication Issue
Per the release
Per the release notes, there are some enhancements to logical replication
that came after 11.5 like 11.8 particularly related to replication identity
full. Do you have a primary key or unique index that is being used for the
replication identity?
Hi,
I have set up logical replication from an AWS RDS instance to a postgreSQL
database on an EC2 instance. I am getting an “out of memory” error during the
initial for one of the tables. I have include a snippet of the error at the
bottom of this email. The snippet below repeats every four or e
On 4/17/20 7:47 AM, Sonam Sharma wrote:
Yes, you are right. It's for connection failover from application end. I
have set up db replication using repmgr. Version : 9.5
Can you reach the database crowd at host 172.29.195.216:50001 using psql
or some other client?
On Fri, Apr 17, 2020, 8:
Yes, you are right. It's for connection failover from application end. I
have set up db replication using repmgr. Version : 9.5
On Fri, Apr 17, 2020, 8:15 PM Julien Rouhaud wrote:
> On Fri, Apr 17, 2020 at 4:02 PM Adrian Klaver
> wrote:
> >
> > On 4/17/20 6:31 AM, Sonam Sharma wrote:
> > > I
On Fri, Apr 17, 2020 at 4:02 PM Adrian Klaver wrote:
>
> On 4/17/20 6:31 AM, Sonam Sharma wrote:
> > I have setup db replication. And added below parameter in jdbc file .
> > The connection is failing and it's throwing error like db doesn't exist
> > on secondary server.
> >
> > jdbc:postgresql://
On 4/17/20 6:31 AM, Sonam Sharma wrote:
I have setup db replication. And added below parameter in jdbc file .
The connection is failing and it's throwing error like db doesn't exist
on secondary server.
jdbc:postgresql://:50001,172.29.195.216:50001/crowd?targetServerType=master&reWriteBatchedI
I have setup db replication. And added below parameter in jdbc file . The
connection is failing and it's throwing error like db doesn't exist on
secondary server.
jdbc:postgresql://:50001,
172.29.195.216:50001/crowd?targetServerType=master&reWriteBatchedInserts=true
.PSQLException: FATAL: datab
Hello,
we are using logical replication from PostgreSQL 10.8 (Ubuntu
10.8-1.pgdg14.04+1) to PostgreSQL 11.3 (Ubuntu 11.3-1.pgdg18.04+1). Thre
are 1305 replicated tables within 3 schemas. The tables are from small
almost static lookup tables to larger tables up to ~40GB holding 44
millions of row
On Fri, 2019-10-04 at 00:34 +1000, Jason Wang wrote:
> I read this
> https://www.2ndquadrant.com/en/blog/evolution-fault-tolerance-postgresql-synchronous-commit/
>
> But don't see why your primary would have more records than the
> standby?
>
> If killall was issued before commit returned, that
I read this
https://www.2ndquadrant.com/en/blog/evolution-fault-tolerance-postgresql-synchronous-commit/
But don't see why your primary would have more records than the standby?
If killall was issued before commit returned, that means the transaction
wasn't completed so yes you would lose records
On Wed, 2019-10-02 at 23:58 +0530, Shital A wrote:
> We are seeing a strange issue with postgresql streaming application
> in sync mode.
>
> We are using postgresql 9.6. Old version because of some specific
> requirements. We have setup cluster with master-standby using
> pacemaker.
>
> When w
On Thu, 3 Oct 2019, 03:10 Jason Wang, wrote:
> I think when you use kill -9 it wouldn't give any chance for postgres to
> do what it normally does. So in your case, the db was killed with no chance
> to apply to remote then it would be up to the recovery to decide how to
> handle the extra data a
On Thu, 3 Oct 2019, 00:08 Ravi Krishna, wrote:
> >
> > As the failed primary is having more data, How is it possible that
> primary is committing transaction before they were applied on standby with
> synchronous_commit=remote_apply?
>
> If I am not mistaken remote_apply is only from ver 11.
>
H
>
> As the failed primary is having more data, How is it possible that primary is
> committing transaction before they were applied on standby with
> synchronous_commit=remote_apply?
If I am not mistaken remote_apply is only from ver 11.
Hello,
We are seeing a strange issue with postgresql streaming application in sync
mode.
We are using postgresql 9.6. Old version because of some specific
requirements. We have setup cluster with master-standby using pacemaker.
When we kill master using killall -9 postgres. The failed primary h
Hello,
I've found an issue with logical replication causing
1) large memory allocation by wal sender process (RSS 60GB)
2) large amount of "xid" files in $PGDATA/pg_replslot/
directory - seems to be amount of rows handled by trigger + few more
Having several millions of files in a single director
27 matches
Mail list logo
