Sorry, I didn´t explain exactly what I was doing, I just wrote "This
replication is a auditing database" on my second email.
Atenciosamente,
Em seg., 29 de nov. de 2021 às 09:20, Amit Kapila
escreveu:
> On Mon, Nov 29, 2021 at 5:04 PM Marcos Pegoraro wrote:
> >>
> >> On thinking about this
On Mon, Nov 29, 2021 at 5:04 PM Marcos Pegoraro wrote:
>>
>> On thinking about this point again, it is not clear to me why that
>> would matter for this particular use case? Basically, when you create
>> a new subscription, it should copy the entire existing data from the
>> table directly and the
>
> On thinking about this point again, it is not clear to me why that
> would matter for this particular use case? Basically, when you create
> a new subscription, it should copy the entire existing data from the
> table directly and then will decode changes from WAL. So, I think in
> your case al
On Fri, Nov 26, 2021 at 5:47 PM Marcos Pegoraro wrote:
>>
>> So, in short, I think what we need to solve is to get the data from
>> new tables and newly performed writes on old tables. I could think of
>> the following two approaches:
>>
>> Approach-1:
>> 1. Drop subscription and Truncate all tabl
>
> I think we don't want to make assumptions about the remote end being
> the same after the upgrade and we let users reactivate the
> subscriptions in a suitable way. See [1] (Start reading from "..When
> dumping logical replication subscriptions..") In your case, if you
> wouldn't have allowed n
On Fri, Nov 26, 2021 at 5:47 PM Marcos Pegoraro wrote:
>>
>> AFAIU the main problem in your case is that you didn't block the write
>> traffic on the publisher side. Let me try to understand the situation.
>> After the upgrade is finished, there are some new tables with data on
>> the publisher, a
>
> AFAIU the main problem in your case is that you didn't block the write
> traffic on the publisher side. Let me try to understand the situation.
> After the upgrade is finished, there are some new tables with data on
> the publisher, and did old tables have any additional data?
>
Correct.
>
> A
On Thu, Nov 25, 2021 at 8:00 PM Marcos Pegoraro wrote:
>>
>> Yes, the way you are doing I think it is bound to happen. There is
>> some discussion about why this is happening in email [2]. AFAIK, it is
>> not documented and if so, I think it will be a good idea to document
>>
> And my problem rema
>
> The reason is after an upgrade, there won't be any data in
> pg_subscription_rel, and only when you tried to refresh it is trying
> to sync again which leads to the "duplicate key value ..." problem you
> are seeing.
>
> So, is pg_upgrade populating pg_subscription and not pg_subscription_rel ?
On Thu, Nov 25, 2021 at 5:13 PM Marcos Pegoraro wrote:
>
> A publication for all tables was running fine, Master is a PostgreSQL 11.11.
> Replica was running version 13 (don´t remember minor version).
>
> Then we tried to update only subscriber server, nothing was done on master
> side.
>
> Then
A publication for all tables was running fine, Master is a PostgreSQL
11.11. Replica was running version 13 (don´t remember minor version).
Then we tried to update only subscriber server, nothing was done on master
side.
Then we did ...
- installed postgresql-14.
- configured postgresql.conf to b
11 matches
Mail list logo
