Re: How to shorten a chain of logically replicated servers - Mailing list pgsql-general

From Mike Lissner
Subject Re: How to shorten a chain of logically replicated servers
Date
Msg-id CAMp9=EwJBriURvgoEEKnHRzZf79SpL-6Ai9+8=XVm4xfb-m1Ag@mail.gmail.com
Whole thread Raw
In response to Re: How to shorten a chain of logically replicated servers  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
That's a good trick, thanks again for the help.

Boy, this promises to be a dumb process! I'm unqualified to guess at
what might make this easier, but it does seem like something that
should have some kind of low-level tools that could do the job.

On Wed, Jan 8, 2020 at 1:53 AM Laurenz Albe <laurenz.albe@cybertec.at> 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 data modification for a
> > period of time. Is there a trick here? This is feeling a bit hopeless.
>
> The simplest solution would be to stop the applications that use PostgreSQL.
>
> You could block client connections using a "pg_hba.conf" entry
> (and kill the established connections).
>
> Another option can be to set "default_transaction_read_only = on",
> but that will only work if the clients don't override it explicitly.
>
> Yours,
> Laurenz Albe
> --
> Cybertec | https://www.cybertec-postgresql.com
>



pgsql-general by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Setting up an environment of EDB Advance server
Next
From: Mike Lissner
Date:
Subject: Is it safe to transfer logical replication publication/subscription?