We maintain c.50 logical replicas. Typically the producer version is 12 or 13,
and the subscriber version is 14. We intend to upgrade the subscribers to 15
using pg_upgrade. However, we ran into an unexpected problem with that
approach. I couldn't find much being mentioned about it on the web,
Hi Depesz,
On Thu, 2 Mar 2023, at 12:29, hubert depesz lubaczewski wrote:
> This might be a bit different answer from what you expect, but have you
> seen pgl_ddl_deploy project?
Thanks --- I was unaware of this project so I will take a look.
However, we are operating under a limitation that the
Hello all,
We are using event triggers to capture DDL for subsequent replay on a logical
replica.
The intention is to write the DDL statement to a table, inside the same
transaction that executes the DDL, and have a separate process on the replica
notice changes in this table and execute whate
message to the output plugin for the logical replication
>slot (which in this case is the internal pgoutput one). Given that, I don't
>see how it can be user error. Unless anyone else knows differently?
-Joe
On Tue, 31 Jan 2023, at 18:10, Joe Wildish wrote:
> Hello,
>
> We ha
Hello,
We have a logical replication publisher (13.7) and subscriber (14.6) where we
are seeing the following error on the subscriber. IP address and publication
name changed, otherwise verbatim:
2023-01-31 15:24:49 UTC:x.x.x.x(56276):super@pubdb:[1040971]: WARNING: tables
were not subscribed
Hi Tomas,
On Tue, 16 Nov 2021, at 22:03, Tomas Vondra wrote:
> It sure smells like a case of correlated data for some clients but not
> others, but who knows ... Hard to say without seeing the nodes below the
> join. If the lower nodes are estimated accurately, then it's the join
> selectivity th
Hello,
I am struggling with a problem that appears planning related. I'm hoping folk
here may be able to advise on how best to tackle the issue.
We have a system that ingests JSON messages containing order data. The data
from these messages is inserted into a normalised table structure; "order"
Hi Tom,
> On 16 Apr 2019, at 00:58, Tom Lane wrote:
>
> Joe Wildish writes:
>> We are seeing an inexplicable behaviour when issuing an "UPDATE..RETURNING"
>> statement. I am unsure if it is a Postgres bug. Additional eyes-on would be
>> much appreica
Hello all,
We are seeing an inexplicable behaviour when issuing an "UPDATE..RETURNING"
statement. I am unsure if it is a Postgres bug. Additional eyes-on would be
much appreicated.
When issuing the following statement we are seeing multiple rows UPDATE'd
despite the use of LIMIT 1 and despite
