https://www.postgresql.org/about/news/1851/ This update for postgresql10 fixes the following issues: PostgreSQL 10 was updated to 10.5: <a href=“https://www.postgresql.org/about/news/1851/”>https://www.postgresql.org/about/news/1851/</a> <a href=“https://www.postgresql.org/docs/current/static/release-10-5.html”>https://www.postgresql.org/docs/current/static/release-10-5.html</a> A dump/restore is not required for those running 10.X. However, if you Security issues fixed: This update was imported from the SUSE:SLE-15:Update update project.Security update for postgresql10 (moderate)
use the adminpack extension, you should update it as per the first
changelog entry below. Also, if the function marking mistakes mentioned in
the second and third changelog entries below affect you, you will want to
take steps to correct your database catalogs.
pg_logfile_rotate() function pg_logfile_rotate() is a deprecated wrapper
for the core function pg_rotate_logfile(). When that function was
changed to rely on SQL privileges for access control rather than a
hard-coded superuser check, pg_logfile_rotate() should have been updated
as well, but the need for this was missed. Hence, if adminpack is
installed, any user could request a logfile rotation, creating a minor
security issue. After installing this update, administrators should
update adminpack by performing ALTER EXTENSION adminpack UPDATE in each
database in which adminpack is installed (bsc#1091610).
between connections. If an affected version of libpq was used with
"host" or "hostaddr" connection parameters from untrusted input,
attackers could have bypassed client-side connection security features,
obtain access to higher privileged connections or potentially cause
other impact SQL injection, by causing the PQescape() functions to
malfunction (bsc#1104199)
involved with "INSERT … ON CONFLICT DO UPDATE". An attacker with
"CREATE TABLE" privileges could have exploited this to read arbitrary
bytes server memory. If the attacker also had certain "INSERT" and
limited "UPDATE" privileges to a particular table, they could have
exploited this to update
other columns in the same table (bsc#1104202).