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
-
Fix issues in binary_upgrade_logical_slot_has_caught_up().
- 0bf62460bb9e 17.0 landed
-
Fix a random failure in 003_logical_slots.pl.
- 63c5df126abb 17.0 landed
-
Fix a test in 003_logical_slots.
- 3e36e48d8efe 17.0 landed
-
Fix uninitialized slot array access during the upgrade.
- a7db71ed2787 17.0 landed
-
Fix the test 003_logical_slots.
- 8af917be6bad 17.0 landed
-
Commit b195e6d482 forgot to update meson.build.
- 8949b978ff49 17.0 landed
-
Use shorter file names in the upgrade logical slots test.
- b195e6d482b8 17.0 landed
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 landed
-
Flush logical slots to disk during a shutdown checkpoint if required.
- e0b2eed047df 17.0 landed
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited