non port: databases/postgresql11-server/pkg-plist-client |
Number of commits found: 5 |
Sunday, 31 Dec 2023
|
00:06 Muhammad Moinur Rahman (bofh)
databases/postgresql11: Sunset
bbd8259 |
Thursday, 19 May 2022
|
13:36 Palle Girgensohn (girgen)
databases/postgresql??-*: add postgresql-15 to the ports tree
Introduce PostgreSQL-15 to the ports tree.
Make version 15 the master port, and add plist parameter for the
postgresql version.
Release notes: https://www.postgresql.org/docs/devel/release.html
5b11f47 |
Thursday, 13 Aug 2020
|
13:45 girgen
The PostgreSQL Global Development Group has released an update to all
supported versions of our database system, including 12.4, 11.9, 10.14,
9.6.19, and 9.5.23.
This release closes two security vulnerabilities and fixes over 50 bugs
reported over the last three months.
Please plan to update at your earliest convenience.
Security Issues
---------------
* CVE-2020-14349: Uncontrolled search path element in logical replication.
Versions Affected: 10 - 12.
The PostgreSQL `search_path` setting determines schemas searched for
tables, functions, operators, etc. The CVE-2018-1058 fix caused most
PostgreSQL-provided client applications to sanitize `search_path`, but
logical replication continued to leave `search_path` unchanged. Users of
a replication publisher or subscriber database can create objects in the
`public` schema and harness them to execute arbitrary SQL functions
under the identity running replication, often a superuser. Installations
having adopted a documented secure schema usage pattern are not vulnerable.
The PostgreSQL project thanks Noah Misch for reporting this problem.
* CVE-2020-14350: Uncontrolled search path element in `CREATE EXTENSION`.
Versions Affected: 9.5 - 12. The security team typically does not test
unsupported versions, but this problem is quite old.
When a superuser runs certain `CREATE EXTENSION` statements, users may
be able to execute arbitrary SQL functions under the identity of that
superuser. The attacker must have permission to create objects in the
new extension's schema or a schema of a prerequisite extension. Not all
extensions are vulnerable.
In addition to correcting the extensions provided with PostgreSQL, the
PostgreSQL Global Development Group is issuing guidance for third-party
extension authors to secure their own work.
The PostgreSQL project thanks Andres Freund for reporting this problem.
Security: CVE-2020-14349, CVE-2020-14350
|
Friday, 15 Feb 2019
|
11:02 girgen
The PostgreSQL Global Development Group has released an update to all
supported versions of our database system, including 11.2, 10.7, 9.6.12,
9.5.16, and 9.4.21. This release changes the behavior in how PostgreSQL
interfaces with `fsync()` and includes fixes for partitioning and over
70 other bugs that were reported over the past three months.
Users should plan to apply this update at the next scheduled downtime.
FreeBSD port adds OPTIONS knob to support LLVM JIT. [1]
Highlight: Change in behavior with fsync()
------------------------------------------
When available in an operating system and enabled in the configuration
file (which it is by default), PostgreSQL uses the kernel function
`fsync()` to help ensure that data is written to a disk. In some
operating systems that provide `fsync()`, when the kernel is unable to
write out the data, it returns a failure and flushes the data that was
supposed to be written from its data buffers.
This flushing operation has an unfortunate side-effect for PostgreSQL:
if PostgreSQL tries again to write the data to disk by again calling
`fsync()`, `fsync()` will report back that it succeeded, but the data
that PostgreSQL believed to be saved to the disk would not actually be
written. This presents a possible data corruption scenario.
This update modifies how PostgreSQL handles a `fsync()` failure:
PostgreSQL will no longer retry calling `fsync()` but instead will
panic. In this case, PostgreSQL can then replay the data from the
write-ahead log (WAL) to help ensure the data is written. While this may
appear to be a suboptimal solution, there are presently few alternatives
and, based on reports, the problem case occurs extremely rarely.
A new server parameter `data_sync_retry` has been added to manage this
behavior. If you are certain that your kernel does not discard dirty
data buffers in such scenarios, you can set `data_sync_retry` to `on` to
restore the old behavior.
Release Notes: https://www.postgresql.org/about/news/1920/
PR: 232490 [1]
|
Friday, 19 Oct 2018
|
21:32 girgen
The PostgreSQL Global Development Group today announced the release of
PostgreSQL 11, the latest version of the world's most advanced open
source database.
PostgreSQL 11 provides users with improvements to overall performance of
the database system, with specific enhancements associated with very
large databases and high computational workloads. Further, PostgreSQL 11
makes significant improvements to the table partitioning system, adds
support for stored procedures capable of transaction management,
improves query parallelism and adds parallelized data definition
capabilities, and introduces just-in-time (JIT) compilation for
accelerating the execution of expressions in queries.
"For PostgreSQL 11, our development community focused on adding features
that improve PostgreSQL's ability to manage very large databases," said (Only the first 15 lines of the commit message are shown above )
|
Number of commits found: 5 |