[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: Trying to understand a failed upgrade in AWS RDS
From: Alan Hodgson <ahodgson () lists ! simkin ! ca>
Date: 2023-05-23 15:02:20
Message-ID: 327a821bc88b41fc15cc04f18695e2d20d874312.camel () lists ! simkin ! ca
[Download RAW message or body]
On Sun, 2023-05-21 at 07:56 -0700, Mike Lissner wrote:
> > 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 it work with some efforts in some basic
> > configurations and / or if no changes happen on the publications
> >
>
>
> But that kind of surprises me too, actually, because it seemed like
> pg_upgrade wiped out the LSN locations of the subcriber, making it
> start all over.
>
> Upgrading a subscriber seems like something that could/should work,
> so it should be documented if pg_upgrade is incompatible with
> maintaining a subscription, shouldn't it?
The docs are strangely silent on this. AFAIK pg_upgrade on either the
publisher or subscriber breaks logical replication, which does make
sense since pg_upgrade basically makes a new database cluster as it
runs.
There is a way to manually set the LSN position of an enabled=false
replication slot, but I've failed to make that work right in tests so
far.
[Attachment #3 (text/html)]
<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>On Sun, 2023-05-21 at 07:56 -0700, Mike Lissner \
wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div \
class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px \
#729fcf solid;padding-left:1ex"><div dir="auto"><div dir="auto">As far as I know it's \
impossible to reliably pg_upgrade a node that has subscriptions and eventually resume \
logical replication. </div></div><br></blockquote><div><br></div><div>Should \
this go in the documentation somewhere? Maybe in the pg_upgrade notes? I still don't \
understand the mechanism. You also say that:<br></div><div> </div><blockquote \
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">It's \
possible to make it work with some efforts in some basic configurations and / or if \
no changes happen on the \
publications</div></div><br></blockquote><div><br></div><div>But that kind of \
surprises me too, actually, because it seemed like pg_upgrade wiped out the LSN \
locations of the subcriber, making it start all \
over.</div><div><br></div><div>Upgrading a subscriber seems like something that \
could/should work, so it should be documented if pg_upgrade is incompatible with \
maintaining a subscription, shouldn't it? \
<br></div></div></div></blockquote><div><br></div><div>The docs are strangely silent \
on this. AFAIK pg_upgrade on either the publisher or subscriber breaks logical \
replication, which does make sense since pg_upgrade basically makes a new database \
cluster as it runs.</div><div><br></div><div>There is a way to manually set the LSN \
position of an enabled=false replication slot, but I've failed to make that work \
right in tests so far.</div><div><span></span></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic