Bug 34306 - /usr/lib64/postgresql/plpgsql.so: undefined symbol: ReleaseAllPlanCacheRefsInOwner
Summary: /usr/lib64/postgresql/plpgsql.so: undefined symbol: ReleaseAllPlanCacheRefsIn...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Nicolas Salguero
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-26 02:22 CEST by Pierre Fortin
Modified: 2025-07-05 19:58 CEST (History)
1 user (show)

See Also:
Source RPM: postgresql17-plpgsql-17.5-1.mga10.x86_64
CVE:
Status comment:


Attachments

Description Pierre Fortin 2025-05-26 02:22:43 CEST
Description of problem: Unable to init new DB
[postgres@pf ~]$ initdb -E UTF8 /var/lib/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /var/lib/pgsql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... US/Eastern
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... 2025-05-25 19:58:08.701 EDT [4068763] FATAL:  could not load library "/usr/lib64/postgresql/plpgsql.so": /usr/lib64/postgresql/plpgsql.so: undefined symbol: ReleaseAllPlanCacheRefsInOwner
2025-05-25 19:58:08.701 EDT [4068763] STATEMENT:  CREATE EXTENSION plpgsql;

child process exited with exit code 1
initdb: removing data directory "/var/lib/pgsql/data"
[postgres@pf ~]$ 

Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. install or upgrade to 17.5...
   Dialog has "Upgrade information about this package" but the info box is empty.
2. try to init new DB
3.

Reverted back to 15.13
Comment 1 Jani Välimaa 2025-05-28 15:58:36 CEST
Can't reproduce the issue with fresh postgresql17-plpgsql install.

[postgres@ThinkPad ~]$ initdb -E UTF8 /var/lib/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /var/lib/pgsql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Europe/Helsinki
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    pg_ctl -D /var/lib/pgsql/data -l logfile start

[postgres@ThinkPad ~]$ rpm -qa postgresql17-plpgsql
postgresql17-plpgsql-17.5-1.mga10
Comment 2 Jani Välimaa 2025-05-29 09:38:16 CEST
Undefined symbol error is caused by a missing postgresql17-server package.

When updating from previous version to postgresql17, urpmi fails and exits with code 1 if /var/lib/pgsql/data/ exists. Thus postgresql17-server never gets installed.

$ LC_ALL=C sudo urpmi postgresql17-server

installing postgresql17-server-17.5-1.mga10.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #########################################################################################################

You currently have database tree for Postgresql 15
You must use postgresql15-server
To update you Postgresql server, dump your databases
delete /var/lib/pgsql/data/ content, upgrade the server, then
restore your databases from your backup

error: %prein(postgresql17-server-17.5-1.mga10.x86_64) scriptlet failed, exit status 1
ERROR: 'script' failed for postgresql17-server-17.5-1.mga10.x86_64
error: postgresql17-server-17.5-1.mga10.x86_64: install failed
Comment 3 Pierre Fortin 2025-05-29 16:05:54 CEST
THANKS for this info...

(In reply to Jani Välimaa from comment #2)
> Undefined symbol error is caused by a missing postgresql17-server package.
> 
> When updating from previous version to postgresql17, urpmi fails and exits
> with code 1 if /var/lib/pgsql/data/ exists. Thus postgresql17-server never
> gets installed.

I didn't see an error (doesn't mean it didn't get reported), so my bad for not noticing the server didn't get intalled

> $ LC_ALL=C sudo urpmi postgresql17-server

> You currently have database tree for Postgresql 15
> You must use postgresql15-server
> To update you Postgresql server, dump your databases
> delete /var/lib/pgsql/data/ content, upgrade the server, then
> restore your databases from your backup

Yikes! My DB is nearly 8TB with no other disk (70TB total) has this much space left. When I upgraded 13 to 15, I used the hard link method which requires both old and new servers be available (see -k|--link option at https://www.postgresql.org/docs/current/pgupgrade.html).
I have all the source data used to populate the DB; but it would take 10+ days to reload it all & why I need to use use something like this:
    systemctl stop postgresql.service
    mv /var/lib/pgsql/data /var/lib/pgsql/data_old
    ## install latest PG ##
    initdb -E UTF8 /var/lib/pgsql/data
    /usr/bin/pg_upgrade \
	--old-bindir=/usr/bin/... \  # PG15
	--new-bindir=/usr/bin/... \  # PG17
	-d /var/lib/pgsql/data_old \
	-D /var/lib/pgsql/data \
	--link \                     # <---
	-U postgres
    systemctl start postgresql.service

So removing the old PG when installing a new PG is problematic.

Any thoughts on this?

See also https://www.postgresql.eu/events/pgconfde2023/sessions/session/4525/slides/397/pg_upgrades_2023.pdf
Comment 4 Lewis Smith 2025-05-30 22:10:45 CEST
Thank you for picking this up, Jani.
(In reply to Jani Välimaa from comment #2)

> Undefined symbol error is caused by a missing postgresql17-server package.
> When updating from previous version to postgresql17, urpmi fails and exits
> with code 1 if /var/lib/pgsql/data/ exists. Thus postgresql17-server never
> gets installed.
> ...
> error: %prein(postgresql17-server-17.5-1.mga10.x86_64) scriptlet failed,
> exit status 1
> ERROR: 'script' failed for postgresql17-server-17.5-1.mga10.x86_64
> error: postgresql17-server-17.5-1.mga10.x86_64: install failed
Is there a packaging error to correct here?

CC: (none) => lewyssmith

Comment 5 Lewis Smith 2025-06-08 21:17:20 CEST
ns80 does postgresql17, so assigning to him.
CC'ing Jani who already commented.

CC: lewyssmith => jani.valimaa
Assignee: bugsquad => nicolas.salguero

Comment 6 Pierre Fortin 2025-07-05 19:58:39 CEST
After switching email providers (old one was obstinate about refusing to fix improper use of DKIM-Signature which pgsql-general@lists.postgresql.org bounced), I was finally able to post this question on the PostgreSQL mailing list:

Wanting to upgrade from:
PostgreSQL 15.13 on x86_64-mageia-linux-gnu, 
compiled by gcc (Mageia 15.1.0-1.mga10) 15.1.0, 64-bit
to:
PG 17.5 

Way back, I was able to use -k|--link option on pg_upgrade (PG13 to PG15);
but since then:

- my DB has grown to over 8TB
- even with ~70TB, I don't have enough contiguous disk space to
  dump/restore
- my Linux distro (Mageia) is not setup to handle multiple versions of
  postgres (installing 17.5 removes 15.13). Worse, it failed to install
  part of the module when it saw /var/lib/pgsql/data still there:
  https://bugs.mageia.org/show_bug.cgi?id=34306

I've glanced at the pg_upgrade source code (my C skills are ancient) and
it appears pg_upgrade is virtually the same from 15.13 to 17.5.

My question:  did I miss anything, or would:
$ pg_upgrade -d data15 -D data17 -k
suffice?

Besides not noticing significant difference between the two versions, the
docs at https://www.postgresql.org/docs/current/pgupgrade.html 
contain: "default is the directory where pg_upgrade resides" 

If new pg_upgrade is the only binary, will both -b and -B default to it?
Maybe at minimum I may need to specify:
$ pg_upgrade -b /usr/bin -d data15 -D data17 -k
?

To which, one of the developers wrote back:

Ugh.  You cannot do pg_upgrade without a copy of the old postgres
server binary as well as the new one.  pg_upgrade by itself is not
capable of accessing either set of catalogs.

Way back when I was packaging PG for Red Hat, they didn't support
multiple concurrently-installed package versions either, so what I did
was to provide an auxiliary pg_upgrade package that contained an old
server binary as well as pg_upgrade itself.  Perhaps Mageia has done
something similar, or could be cajoled to once you point out that
their packaging makes it impossible to do an upgrade.

If that path yields no joy, you'll need to use a hand-built copy of
one PG version or the other while performing the upgrade.

Note You need to log in before you can comment on or make changes to this bug.