pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: hubert depesz lubaczewski <depesz@depesz.com>
To: vignesh C <vignesh21@gmail.com>
Cc: pgsql-bugs mailing list <pgsql-bugs@postgresql.org>
Subject: Re: Logical replication stops dropping used initial-sync replication slots
Date: Tue, 22 Mar 2022 04:48:47 +0100
Message-ID: <20220322034847.GA15952@depesz.com> (raw)
In-Reply-To: <CALDaNm1S-DtphU51d3orNknjyNQEjAOL90jXAxkis_n4rtS=eA@mail.gmail.com>
References: <20220317142426.GA727@depesz.com>
	<20220318122758.GA25022@depesz.com>
	<CALDaNm0+k0M6SDSVEsRWoS8VkwYtTz3WAQcjPWRheKu2-ym-pQ@mail.gmail.com>
	<20220321144341.GA27089@depesz.com>
	<CALDaNm1S-DtphU51d3orNknjyNQEjAOL90jXAxkis_n4rtS=eA@mail.gmail.com>

On Tue, Mar 22, 2022 at 08:37:07AM +0530, vignesh C wrote:
> I could simulate the similar problem by starting a new transaction
> while creating a subscription and notice the following log content:
...
> I'm not sure if this is the same scenario or not.
> Could you also confirm from pg_stat_activity and pg_locks if there are
> any open transactions and if there is any open transaction, could you
> see this transaction is on which relation and are these because of the
> table sync workers?

I don't think it is the same scenario because this is totally isolated
server, with no applications running, cron stopped and no access from
outside whatsoever.
Also, even if I'd assume that some open transaction can pause initial
sync, which is reasonable, why would it start to leave open replication
slots, and start new ones, above number specified in
max_sync_workers_per_subscription?

> Also as an alternative you might be able to use pg_dump to take a
> backup and restore it to the destination if there are no transactions
> and create subscription with copy_data as off.

That wouldn't do me any good. The server I'm trying to upgrade now is
test bench to make sure that I can upgrade using logical replication *at
all*.
Once I will have verified that I can, I have couple hundred servers to
upgrade, that will have concurrent access all the time.

If the problem was: upgrade server that doesn't have any traffic,
I could just pg_dump + pg_restore, and be done with it. Unfortunately
this is not the case.

Best regards,

depesz






view thread (12+ messages)  latest in thread

Message-ID: <20220322034847.GA15952@depesz.com>
Permalink:  ../20220322034847.GA15952@depesz.com/
Also on:    postgresql.org/message-id/20220322034847.GA15952@depesz.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: depesz@depesz.com, vignesh21@gmail.com
  Subject: Re: Logical replication stops dropping used initial-sync replication slots
  In-Reply-To: <20220322034847.GA15952@depesz.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox