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

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2023-11-08T08:38:04Z
Lists: pgsql-hackers
On Wed, Nov 8, 2023 at 8:44 AM vignesh C <vignesh21@gmail.com> wrote:
>
> While verifying upgrade of subscriber patch, I found one issue with
> upgrade in verbose mode.
> I was able to reproduce this issue by performing a upgrade with a
> verbose option.
>
> The trace for the same is given below:
> Program received signal SIGSEGV, Segmentation fault.
> __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:126
> 126        ../sysdeps/x86_64/multiarch/strlen-vec.S: No such file or directory.
> (gdb) bt
> #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:126
> #1  0x000055555556f572 in dopr (target=0x7fffffffbb90,
> format=0x55555557859e "\", plugin: \"%s\", two_phase: %s",
> args=0x7fffffffdc40) at snprintf.c:444
> #2  0x000055555556ed95 in pg_vsnprintf (str=0x7fffffffbc10 "slot_name:
> \"ication slots within the database:", count=8192, fmt=0x555555578590
> "slot_name: \"%s\", plugin: \"%s\", two_phase: %s",
>     args=0x7fffffffdc40) at snprintf.c:195
> #3  0x00005555555667e3 in pg_log_v (type=PG_VERBOSE,
> fmt=0x555555578590 "slot_name: \"%s\", plugin: \"%s\", two_phase: %s",
> ap=0x7fffffffdc40) at util.c:184
> #4  0x0000555555566b38 in pg_log (type=PG_VERBOSE, fmt=0x555555578590
> "slot_name: \"%s\", plugin: \"%s\", two_phase: %s") at util.c:264
> #5  0x0000555555561a06 in print_slot_infos (slot_arr=0x555555595ed0)
> at info.c:813
> #6  0x000055555556186e in print_db_infos (db_arr=0x555555587518
> <new_cluster+120>) at info.c:782
> #7  0x00005555555606da in get_db_rel_and_slot_infos
> (cluster=0x5555555874a0 <new_cluster>, live_check=false) at info.c:308
> #8  0x000055555555839a in check_new_cluster () at check.c:215
> #9  0x0000555555563010 in main (argc=13, argv=0x7fffffffdf08) at
> pg_upgrade.c:136
>
> This issue occurs because we are accessing uninitialized slot array information.
>
> We could fix it by a couple of ways: a) Initialize the whole of
> dbinfos by using pg_malloc0 instead of pg_malloc which will ensure
> that the slot information is set to 0.
>

I would prefer this fix instead of initializing the slot array at
multiple places. I'll push this tomorrow unless someone thinks
otherwise.

-- 
With Regards,
Amit Kapila.



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.