non port: databases/postgresql95-contrib/Makefile |
Number of commits found: 13 |
Sunday, 13 Jun 2021
|
10:50 Rene Ladan (rene)
*/*: Remove expired ports:
2021-06-13 databases/postgresql95-client: PostgreSQL-9.5 has reached end-of-life
2021-06-13 databases/postgresql95-contrib: PostgreSQL-9.5 has reached
end-of-life
2021-06-13 databases/postgresql95-docs: PostgreSQL-9.5 has reached end-of-life
2021-06-13 databases/postgresql95-pgtcl: PostgreSQL-9.5 has reached end-of-life
2021-06-13 databases/postgresql95-plperl: PostgreSQL-9.5 has reached end-of-life
2021-06-13 databases/postgresql95-plpython: PostgreSQL-9.5 has reached
end-of-life
2021-06-13 databases/postgresql95-pltcl: PostgreSQL-9.5 has reached end-of-life
2021-06-13 databases/postgresql95-server: PostgreSQL-9.5 has reached end-of-life
databases/pg_reorg: abandonware only for PostgreSQL 9.5
databases/pgespresso: functionality part of PostgreSQL 9.6 and later
a3da90c |
Thursday, 20 May 2021
|
14:38 Palle Girgensohn (girgen)
databases/postgresql14-*: Add postgresql 14 beta1 the the ports tree.
Release notes: https://www.postgresql.org/docs/devel/release-14.html
Also reintroduce parallel builds. Some components, namely plperl,
plpython, pltcl and contrib, fail to build properly when using parallel
builds. Something with static linking using `ar` that fails.
MAKE_JOBS_UNSAFE is set for these ports.
fccc45e |
Tuesday, 6 Apr 2021
|
14:31 Mathieu Arnold (mat)
Remove # $FreeBSD$ from Makefiles.
305f148 |
Friday, 25 Sep 2020
|
15:53 girgen
Fix depenedency for postgresql13-contrib
And avoid hardcoding the version for all other versions as well, per suggestion
in the PR.
PR: 249888
Submitted by: Christian Ullrich
 |
Thursday, 8 Aug 2019
|
15:33 girgen
iThe PostgreSQL Global Development Group has released an update to all
supported versions of our database system, including 11.5, 10.10,
9.6.15, 9.5.19, and 9.4.24, as well as the third beta of PostgreSQL 12.
This release fixes two security issues in the PostgreSQL server, two
security issues found in one of the PostgreSQL Windows installers, and
over 40 bugs reported since the previous release.
Users should install these updates as soon as possible.
A Note on the PostgreSQL 12 Beta
================================
In the spirit of the open source PostgreSQL community, we strongly
encourage you to test the new features of PostgreSQL 12 in your database
systems to help us eliminate any bugs or other issues that may exist.
While we do not advise you to run PostgreSQL 12 Beta 3 in your
production environments, we encourage you to find ways to run your
typical application workloads against this beta release.
Your testing and feedback will help the community ensure that the
PostgreSQL 12 release upholds our standards of providing a stable,
reliable release of the world's most advanced open source relational
database.
Security Issues
===============
Two security vulnerabilities have been closed by this release:
* CVE-2019-10208: `TYPE` in `pg_temp` executes arbitrary SQL during
`SECURITY DEFINER` execution
Versions Affected: 9.4 - 11
Given a suitable `SECURITY DEFINER` function, an attacker can execute
arbitrary SQL under the identity of the function owner. An attack
requires `EXECUTE` permission on the function, which must itself contain
a function call having inexact argument type match. For example,
`length('foo'::varchar)` and `length('foo')` are inexact, while
`length('foo'::text)` is exact. As part of exploiting this
vulnerability, the attacker uses `CREATE DOMAIN` to create a type in a
`pg_temp` schema. The attack pattern and fix are similar to that for
CVE-2007-2138.
Writing `SECURITY DEFINER` functions continues to require following the
considerations noted in the documentation:
https://www.postgresql.org/docs/devel/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY
The PostgreSQL project thanks Tom Lane for reporting this problem.
* CVE-2019-10209: Memory disclosure in cross-type comparison for hashed
subplan
Versions Affected: 11
In a database containing hypothetical, user-defined hash equality operators, an
attacker could read arbitrary bytes of server memory. For an attack to become
possible, a superuser would need to create unusual operators. It is possible for
operators not purpose-crafted for attack to have the properties that enable an
attack, but we are not aware of specific examples.
The PostgreSQL project thanks Andreas Seltenreich for reporting this problem.
 |
Friday, 26 Jul 2019
|
20:46 gerald
Bump PORTREVISION for ports depending on the canonical version of GCC
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
 |
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]
 |
Wednesday, 12 Dec 2018
|
01:35 gerald
Bump PORTREVISION for ports depending on the canonical version of GCC
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
 |
Monday, 10 Sep 2018
|
13:14 mat
Add DOCS options to ports that should have one.
Also various fixes related to said option.
PR: 230864
Submitted by: mat
exp-runs by: antoine
 |
Friday, 1 Apr 2016
|
14:00 mat
Remove ${PORTSDIR}/ from dependencies, categories d, e, f, and g.
With hat: portmgr
Sponsored by: Absolight
 |
Wednesday, 13 Jan 2016
|
10:36 girgen
Some binaries where moved from contrib to base in 9.5, like pgbench and
pg_upgrade. Other where added in 9.5, but the port failed to install them.
Make sure they are properly installed by the correct port (-client or -server)
[1]
Remove unused and hence confusing OSSP_UUID parameters from Makefile [2]
Add options to allow user to be set for the backup script in periodic.
Add this option only to 9.5 for now. It will be updated to other servers at
next regular patch release. [3]
The path to perl in hard coded into pgxs/src/Makefile.global which is
then installed. Hence, we must depend on perl when that file is installed.
Noticed by: Paul Guyot [1]
PR: 192387 [2]
PR: 172110 [3]
PR: 206046 [4]
 |
Thursday, 7 Jan 2016
|
21:37 antoine
Fix probable typo (and PKGNAME collision)
While here, fix plist
 |
19:58 girgen
The PostgreSQL Global Development Group announces the
release of PostgreSQL 9.5.
This release adds UPSERT capability, Row Level Security,
and multiple Big Data features, which will broaden the
user base for the world's most advanced database.
With these new capabilities, PostgreSQL will be
the best choice for even more applications for startups,
large corporations, and government agencies.
Release Notes:
http://www.postgresql.org/docs/current/static/release-9-5.html
What's New in 9.5:
https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.5
 |
Number of commits found: 13 |