I should have added that the source DB is 16.1 and the target is 16.0
I am trying to discover the causes of occasional data loss in logical
replication; it is VERY rare and happens every few week/months.
Our setup is a source DB running in docker on AWS cloud server. The
source database is stored in on local disks on the cloud server.
The replication target is
...patch actually attached this time...
> > I as far as I can tell, pg_dump does not dup the ‘run_as_owner` setting for
> > a subscription.
> >
> > Should it? Should I submit a patch? It seems pretty trivial to fix if
> > anyone else is working on it.
>
> Yes, it certainly should. That is an
> > I as far as I can tell, pg_dump does not dup the ‘run_as_owner` setting for
> > a subscription.
> >
> > Should it? Should I submit a patch? It seems pretty trivial to fix if
> > anyone else is working on it.
>
> Yes, it certainly should. That is an omission in 482675987b.
> Go ahead and wr
Further to this: it seems that `Alter Subscription X Set(Run_As_Owner=True);`
has no influence on the `subrunasowner` column of pg_subscriptions.
Sent from Mail for Windows
From: Philip Warner
Sent: Friday, 27 October 2023 3:26 PM
To: pgsql-hackers@lists.postgresql.org
Subject: pg_dump not
Hi,
I as far as I can tell, pg_dump does not dup the ‘run_as_owner` setting for a
subscription.
Should it? Should I submit a patch? It seems pretty trivial to fix if anyone
else is working on it.
Sent from Mail for Windows
