OR: replication slot "pg_20031_sync_17402_7324846428853951375" does not
exist
And I thought that maybe there'd be some magic in the REFRESH command on
the subscriber, so I tried that:
alter subscription xyz refresh publication;
To nobody's surprise, that didn't help. :)
On Sun, Feb 25, 2024 at
Hi, I set up logical replication a few days ago, but it's throwing some
weird log lines that have me worried. Does anybody have experience with
lines like the following on a subscriber:
LOG: logical replication table synchronization worker for subscription
"compass_subscription", table
> As far as I know it's impossible to reliably pg_upgrade a node that has
> subscriptions and eventually resume logical replication.
>
Should this go in the documentation somewhere? Maybe in the pg_upgrade
notes? I still don't understand the mechanism. You also say that:
> It's possible to make
S's upgrade (which runs pg_upgrade).
> 5. Recreate replication slots with the same names.
> 6. Enable Application Users on Publisher.
> 7. Re-Enable the subscriptions to the newly upgraded server.
> Good luck
>
> On Fri, May 19, 2023 at 11:49 AM Mike Lissner <
> mliss...@mi
the upgrade using that slot and copy_data=False? Getting wonky.
On Fri, May 19, 2023 at 8:17 AM Mike Lissner
wrote:
> Hi all,
>
> In AWS RDS, we are using logical replication between a postgresql 14
> publisher and a postgresql 10 subscriber. The subscriber is rather old, so
> ye
Hi all,
In AWS RDS, we are using logical replication between a postgresql 14
publisher and a postgresql 10 subscriber. The subscriber is rather old, so
yesterday I tried to update it using AWS's built in upgrade tool (which
uses pg_upgrade behind the scenes).
I did a pretty thorough test run
Hi all,
I've been using logical replication for about a year now, and I wonder if
there's any sense that it needs better documentation of schema changes. My
experience is that there's almost no documentation and that there are lots
of opportunities to really screw things up.
It seems like
On Thu, Jan 23, 2020 at 11:28 AM Adrian Klaver
wrote:
> On 1/23/20 11:17 AM, Mike Lissner wrote:
> > Thanks Adrian. Is there a reason that the index rebuild is nearly
> > instant during the ALTER command as opposed to when you build it from
> > scratch?
>
> Well it d
t;pg_toast_37609"
Thanks for the feedback. I really appreciate it and it's super interesting
to learn about.
Mike
On Thu, Jan 23, 2020 at 9:54 AM Adrian Klaver
wrote:
> On 1/23/20 8:55 AM, Mike Lissner wrote:
> > I think the docs say that if you convert a varchar to text, it'll
> >
I think the docs say that if you convert a varchar to text, it'll rewrite
the index, but my test doesn't seem to indicate that. Is the test or the
documentation wrong?
If the docs, I'll be happy to make a fix my first contribution to
postgresql. :)
Here are the docs:
t 2:46 PM Peter Eisentraut
wrote:
>
> On 2020-01-08 22:22, Mike Lissner wrote:
> > Hi all, this is a follow up from an earlier question I asked about
> > shortening a chain of logically replicating servers. Right now we have
> > three servers replicating like this:
> >
Hi all, this is a follow up from an earlier question I asked about
shortening a chain of logically replicating servers. Right now we have
three servers replicating like this:
A --> B --> C
And we want to remove B so that we have:
A --> C
Is it possible to DROP the subscription on B to A and
wrote:
>
> On Tue, 2020-01-07 at 23:17 -0800, Mike Lissner wrote:
> > > You'd have to suspend all data modification on A in that interval.
> >
> > I know how to stop the DB completely, but I can't think of any obvious
> > ways to make sure that it doesn't get any d
nks for the response, Laurenz.
On Tue, Jan 7, 2020 at 3:11 AM Laurenz Albe wrote:
>
> On Tue, 2019-12-31 at 15:51 -0800, Mike Lissner wrote:
> > Hi, I'm trying to figure out how to shorten a chain of logically
> > replicating servers. Right now we have three servers replicating like
> >
Hi, I don't usually like to bump messages on this list, but since I
sent mine on New Year's Eve, I figured I'd better. Anybody have any
ideas about how to accomplish this? I'm pretty stumped (as you can
probably see).
On Tue, Dec 31, 2019 at 3:51 PM Mike Lissner
wrote:
>
> Hi, I'm
Hi, I'm trying to figure out how to shorten a chain of logically
replicating servers. Right now we have three servers replicating like
so:
A --> B --> C
And I'd like to remove B from the chain of replication so that I only have:
A --> C
Of course, doing this without losing data is the goal. If
I've got a server at example.com that currently publishes logical
replication to a server in AWS RDS. I plan to move the server at example.com
so that it has a new IP address (but same domain name).
I'm curious if anybody knows how the logical replication subscriber in AWS
would handle that.
Thanks Adrian for all the help. I filed this as bug #15549. I hope this all
helps get logical replication into the "Running" stage.
On Wed, Dec 12, 2018 at 5:06 PM Adrian Klaver
wrote:
> On 12/12/18 3:19 PM, Mike Lissner wrote:
> > This sounds *very* plausible. So I th
uld surely help, too.
Mike
On Wed, Dec 12, 2018 at 7:11 AM Adrian Klaver
wrote:
> On 12/12/18 12:15 AM, Mike Lissner wrote:
> >
> >
> > On Tue, Dec 11, 2018 at 3:10 PM Adrian Klaver > <mailto:adrian.kla...@aklaver.com>> wrote:
> >
> >
> >
On Tue, Dec 11, 2018 at 3:10 PM Adrian Klaver
wrote:
>
> > Well, I was able to fix this by briefly allowing nulls on the
> > subscriber, letting it catch up with the publisher, setting all
> > nulls to empty strings (a Django convention), and then disallowing
> > nulls again.
Reupping this since it was over the weekend and looks like a bug in logical
replication. My problems are solved, but some very weird things happened
when doing a schema migration.
On Sun, Dec 9, 2018 at 5:48 PM Mike Lissner
wrote:
> On Sun, Dec 9, 2018 at 12:42 PM Adrian Klaver
>
On Sun, Dec 9, 2018 at 12:42 PM Adrian Klaver
wrote:
>
> 1) Using psql have you verified that NOT NULL is set on that column on
> the publisher?
>
Yes, on the publisher and the subscriber. That was my first step when I saw
the log lines about this.
2) And that the row that failed in the
On Sun, Dec 9, 2018 at 8:43 AM Adrian Klaver
wrote:
> On 12/9/18 8:03 AM, Mike Lissner wrote:
> >
> > The above seems to be the crux of the problem, how did NULL get into
> > the
> > column data?
> >
> >
> > I agree. My queries are generat
>
>
> The above seems to be the crux of the problem, how did NULL get into the
> column data?
>
>
I agree. My queries are generated by Django (so I never write SQL myself),
but:
- the column has always been NOT NULL for its entire lifetime
- we don't send *any* SQL commands to the replica yet,
Hi, first time poster.
I just ran into a rather messy problem when doing a schema migration with
logical replication. I'm not entirely sure what went wrong, why, or how to
prevent it in the future. The migration I ran was pretty simple (though
auto-generated by Django):
BEGIN;ALTER TABLE
25 matches
Mail list logo
