Horton

Re: [PoC] pg_upgrade: allow to upgrade publisher node

Bruce Momjian <bruce@momjian.us>

View thread View on postgr.es
From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, vignesh C <vignesh21@gmail.com>
Date: 2023-08-11T18:03:47Z
Lists: pgsql-hackers 
On Fri, Aug 11, 2023 at 11:18:09AM +0530, Amit Kapila wrote:
> On Fri, Aug 11, 2023 at 10:43 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > I disagree.  As I mentioned before any module registered in
> > shared_preload_libraries can spawn background workers which can perform any
> > activity.  There were previous reports of corruption because of multi-xact
> > being generated by such bgworkers during pg_upgrade, I'm pretty sure that there
> > are some modules that create objects (automatic partitioning tools for
> > instance).  It's also unclear to me what would happen if some writes are
> > performed by such module at various points of the pg_upgrade process.  Couldn't
> > that lead to either data loss or broken slot (as it couldn't stream changes
> > from older major version)?
> 
> It won't be any bad than what can happen to tables. If we know that
> such bgworkers can cause corruption if they do writes during the
> upgrade, I don't think it is the job of this patch to prevent the
> related scenarios. We can probably disallow the creation of new slots
> during the binary upgrade but that also I am not sure. I guess it
> would be better to document such hazards as a first step and then
> probably write a patch to prevent WAL writes or something along those
> lines.

Yes, if users are connecting to the clusters during pg_upgrade, we have
many more problems than slots.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Commits

  1. Fix issues in binary_upgrade_logical_slot_has_caught_up().

  2. Fix a random failure in 003_logical_slots.pl.

  3. Fix a test in 003_logical_slots.

  4. Fix uninitialized slot array access during the upgrade.

  5. Fix the test 003_logical_slots.

  6. Commit b195e6d482 forgot to update meson.build.

  7. Use shorter file names in the upgrade logical slots test.

  8. Migrate logical slots to the new node during an upgrade.

  9. Flush logical slots to disk during a shutdown checkpoint if required.

  10. Prevent possibility of panics during shutdown checkpoint.