Change log for postgresql-9.3 package in Debian
1 → 15 of 15 results | First • Previous • Next • Last |
postgresql-9.3 (9.3.4-2) unstable; urgency=medium * Bump to debhelper 9 to get debug symbol files based on build-ids. * Enable multiarch support in libpq and friends. (Closes: #706849) Support is automatically disabled when the distribution does not support it. * Stop providing/replacing/conflicting with postgresql*-dbg. * Skip -pie on 32bit archs for performance and stability reasons. Closes: #749686; details at http://<email address hidden> -- Christoph Berg <email address hidden> Thu, 29 May 2014 20:17:07 +0200
Available diffs
- diff from 9.3.4-1 to 9.3.4-2 (3.1 KiB)
postgresql-9.3 (9.3.4-1) unstable; urgency=medium * New upstream bugfix release. Most notable change: Fix WAL replay of locking an already-updated tuple (Andres Freund, Álvaro Herrera) This error caused updated rows to not be found by index scans, resulting in inconsistent query results depending on whether an index scan was used. Subsequent processing could result in constraint violations, since the previously updated row would not be found by later index searches, thus possibly allowing conflicting rows to be inserted. Since this error is in WAL replay, it would only manifest during crash recovery or on standby servers. The improperly-replayed case most commonly arises when a table row that is referenced by a foreign-key constraint is updated concurrently with creation of a referencing row. * Compile with -fno-omit-frame-pointer on amd64 to facilitate hierarchical profile generation. (Closes: #730134) * Remove obsolete configure option --with-tkconfig. -- Christoph Berg <email address hidden> Tue, 18 Mar 2014 07:19:37 +0100
Available diffs
- diff from 9.3.3-1bzr2 (in Ubuntu) to 9.3.4-1 (578.7 KiB)
postgresql-9.3 (9.3.3-2) unstable; urgency=medium [ Martin Pitt ] * Add missing build-essential test depends, for 180_ecpg.t. [ Christoph Berg ] * Don't install server includefiles in libpq-dev. (Closes: #314427) * Remove contrib/file_fdw/sql/file_fdw.sql on clean. -- Christoph Berg <email address hidden> Wed, 12 Mar 2014 12:57:20 +0100
postgresql-9.3 (9.3.3-1) unstable; urgency=medium [ Christoph Berg ] * New upstream security/bugfix release. + Shore up GRANT ... WITH ADMIN OPTION restrictions (Noah Misch) Granting a role without ADMIN OPTION is supposed to prevent the grantee from adding or removing members from the granted role, but this restriction was easily bypassed by doing SET ROLE first. The security impact is mostly that a role member can revoke the access of others, contrary to the wishes of his grantor. Unapproved role member additions are a lesser concern, since an uncooperative role member could provide most of his rights to others anyway by creating views or SECURITY DEFINER functions. (CVE-2014-0060) + Prevent privilege escalation via manual calls to PL validator functions (Andres Freund) The primary role of PL validator functions is to be called implicitly during CREATE FUNCTION, but they are also normal SQL functions that a user can call explicitly. Calling a validator on a function actually written in some other language was not checked for and could be exploited for privilege-escalation purposes. The fix involves adding a call to a privilege-checking function in each validator function. Non-core procedural languages will also need to make this change to their own validator functions, if any. (CVE-2014-0061) + Avoid multiple name lookups during table and index DDL (Robert Haas, Andres Freund) If the name lookups come to different conclusions due to concurrent activity, we might perform some parts of the DDL on a different table than other parts. At least in the case of CREATE INDEX, this can be used to cause the permissions checks to be performed against a different table than the index creation, allowing for a privilege escalation attack. (CVE-2014-0062) + Prevent buffer overrun with long datetime strings (Noah Misch) The MAXDATELEN constant was too small for the longest possible value of type interval, allowing a buffer overrun in interval_out(). Although the datetime input functions were more careful about avoiding buffer overrun, the limit was short enough to cause them to reject some valid inputs, such as input containing a very long timezone name. The ecpg library contained these vulnerabilities along with some of its own. (CVE-2014-0063) + Prevent buffer overrun due to integer overflow in size calculations (Noah Misch, Heikki Linnakangas) Several functions, mostly type input functions, calculated an allocation size without checking for overflow. If overflow did occur, a too-small buffer would be allocated and then written past. (CVE-2014-0064) + Prevent overruns of fixed-size buffers (Peter Eisentraut, Jozef Mlich) Use strlcpy() and related functions to provide a clear guarantee that fixed-size buffers are not overrun. Unlike the preceding items, it is unclear whether these cases really represent live issues, since in most cases there appear to be previous constraints on the size of the input string. Nonetheless it seems prudent to silence all Coverity warnings of this type. (CVE-2014-0065) + Avoid crashing if crypt() returns NULL (Honza Horak, Bruce Momjian) There are relatively few scenarios in which crypt() could return NULL, but contrib/chkpass would crash if it did. One practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms (e.g., "FIPS mode"). (CVE-2014-0066) + Document risks of make check in the regression testing instructions (Noah Misch, Tom Lane) Since the temporary server started by make check uses "trust" authentication, another user on the same machine could connect to it as database superuser, and then potentially exploit the privileges of the operating-system user who started the tests. A future release will probably incorporate changes in the testing procedure to prevent this risk, but some public discussion is needed first. So for the moment, just warn people against using make check when there are untrusted users on the same machine. (CVE-2014-0067) + Rework tuple freezing protocol (Álvaro Herrera, Andres Freund) The logic for tuple freezing was unable to handle some cases involving freezing of multixact IDs, with the practical effect that shared row-level locks might be forgotten once old enough. Fixing this required changing the WAL record format for tuple freezing. While this is no issue for standalone servers, when using replication it means that standby servers must be upgraded to 9.3.3 or later before their masters are. An older standby will be unable to interpret freeze records generated by a newer master, and will fail with a PANIC message. (In such a case, upgrading the standby should be sufficient to let it resume execution.) * The upstream tarballs no longer contain a plain HISTORY file, but point to the html documentation. Note the location of these files in our changelog.gz file. * Teach configure to find tclsh8.6 where tclsh is not available. [ Martin Pitt ] * Build with LINUX_OOM_SCORE_ADJ=0 instead of the older LINUX_OOM_ADJ=0. All relevant distro releases (>= squeeze/lucid) use kernels which support /proc/pid/oom_score_adj, so avoid the dmesg warnings. (Closes: #646245, LP: #991725) * Bump Standards-Version to 3.9.5 (no changes necessary). * Build with tcl8.6 where available (>= Jessie, >= trusty). -- Christoph Berg <email address hidden> Wed, 19 Feb 2014 10:15:39 +0100
Available diffs
postgresql-9.3 (9.3.2-1) unstable; urgency=low [ Martin Pitt ] * Add 03-config-update.patch: Refresh config.{guess,sub} to latest version for enabling ports, in particular the upcoming ppc64el. [ Christoph Berg ] * New upstream bugfix release. + Fix "VACUUM"'s tests to see whether it can update relfrozenxid (Andres Freund) In some cases "VACUUM" (either manual or autovacuum) could incorrectly advance a table's relfrozenxid value, allowing tuples to escape freezing, causing those rows to become invisible once 2^31 transactions have elapsed. The probability of data loss is fairly low since multiple incorrect advancements would need to happen before actual loss occurs, but it's not zero. In 9.2.0 and later, the probability of loss is higher, and it's also possible to get "could not access status of transaction" errors as a consequence of this bug. Users upgrading from releases 9.0.4 or 8.4.8 or earlier are not affected, but all later versions contain the bug. The issue can be ameliorated by, after upgrading, vacuuming all tables in all databases while having vacuum_freeze_table_age set to zero. This will fix any latent corruption but will not be able to fix all pre-existing data errors. However, an installation can be presumed safe after performing this vacuuming if it has executed fewer than 2^31 update transactions in its lifetime (check this with SELECT txid_current() < 2^31). + Fix multiple bugs in MultiXactId freezing (Andres Freund, Alvaro Herrera) These bugs could lead to "could not access status of transaction" errors, or to duplicate or vanishing rows. Users upgrading from releases prior to 9.3.0 are not affected. The issue can be ameliorated by, after upgrading, vacuuming all tables in all databases while having vacuum_freeze_table_age set to zero. This will fix latent corruption but will not be able to fix all pre-existing data errors. As a separate issue, these bugs can also cause standby servers to get out of sync with the primary, thus exhibiting data errors that are not in the primary. Therefore, it's recommended that 9.3.0 and 9.3.1 standby servers be re-cloned from the primary (e.g., with a new base backup) after upgrading. + Fix initialization of "pg_clog" and "pg_subtrans" during hot standby startup (Andres Freund, Heikki Linnakangas) This bug can cause data loss on standby servers at the moment they start to accept hot-standby queries, by marking committed transactions as uncommitted. The likelihood of such corruption is small unless, at the time of standby startup, the primary server has executed many updating transactions since its last checkpoint. Symptoms include missing rows, rows that should have been deleted being still visible, and obsolete versions of updated rows being still visible alongside their newer versions. This bug was introduced in versions 9.3.0, 9.2.5, 9.1.10, and 9.0.14. Standby servers that have only been running earlier releases are not at risk. It's recommended that standby servers that have ever run any of the buggy releases be re-cloned from the primary (e.g., with a new base backup) after upgrading. * Refresh debian/patches/62-pg_upgrade-test-in-tmp. -- Christoph Berg <email address hidden> Tue, 03 Dec 2013 09:18:41 +0100
Available diffs
- diff from 9.3.1-1 to 9.3.2-1 (369.5 KiB)
postgresql-9.3 (9.3.1-1) unstable; urgency=low * New upstream release. - Update hstore extension with JSON functionality Users who installed hstore prior to 9.3.1 must execute: ALTER EXTENSION hstore UPDATE; to add two new JSON functions and a cast. - Some bug fixes, see HISTORY for details. -- Martin Pitt <email address hidden> Tue, 08 Oct 2013 10:54:46 +0200
postgresql-9.3 (9.3.0-2) unstable; urgency=low [ Martin Pitt ] * Drop the "beta" warning from package description, this is the final version now. -- Christoph Berg <email address hidden> Tue, 10 Sep 2013 09:34:39 +0200
postgresql-9.3 (9.3.0-1) unstable; urgency=low * New upstream release. * pgxs.mk: Make the install targets depend on installdirs. -- Christoph Berg <email address hidden> Wed, 04 Sep 2013 18:53:05 +0200
postgresql-9.3 (9.3~rc1-2) unstable; urgency=low * Rebuild against Perl 5.18. -- Martin Pitt <email address hidden> Tue, 27 Aug 2013 11:27:10 +0200
postgresql-9.3 (9.3~rc1-1) unstable; urgency=low [ Martin Pitt ] * New upstream release: first 9.3 release candidate. - Add locking around SSL_context usage in libpq, to make it thread safe. (Closes: #718460) * First upload to unstable, 9.3 final will be released soon and now is the time for testing and porting extensions. * debian/rules: Support multi-arch locations of {tcl,tk}-config. * debian/rules: Don't build with kerberos and LDAP support for DEB_STAGE=stage1 to aid with bootstrapping. * debian/tests/control: Add missing net-tools dependency (for ifconfig). * debian/rules: Call dh with --parallel. * debian/control: Explicitly Conflicts/Replaces postgresql-9.1-dbg, as that did not yet have a "Provides: postgresql-dbg". (Closes: #717982) [ Christoph Berg ] * Pull 6697aa2bc25c83b88d6165340348a31328c35de6 and 82b0102650cf85268145a46f0ab488bacf6599a1 from upstream head to better support VPATH builds of PGXS modules. * debian/rules: Call make check-world without -k and use a random port number for pg_regress. -- Martin Pitt <email address hidden> Thu, 22 Aug 2013 10:19:13 +0200
Deleted in experimental-release (Reason: None provided.) |
postgresql-9.3 (9.3~beta2-2) experimental; urgency=low * debian/postgresql-9.3.preinst: Abort upgrade if there are still clusters with the 9.3beta1 format, these need to be dumped/dropped first. (Closes: #714328) -- Martin Pitt <email address hidden> Fri, 28 Jun 2013 14:37:06 +0200
Superseded in experimental-release |
postgresql-9.3 (9.3~beta2-1) experimental; urgency=low [ Christoph Berg ] * hurd-i386: Ignore testsuite failures so we have a working libpq5 (they don't implement semaphores so the server won't even start). * Mark postgresql-9.3 as beta in the description, suggested by Joshua D. Drake. [ Martin Pitt ] * New upstream release 9.3 beta2. -- Martin Pitt <email address hidden> Wed, 26 Jun 2013 15:13:32 +0200
Deleted in experimental-release (Reason: None provided.) |
postgresql-9.3 (9.3~beta1-3) experimental; urgency=low * sparc, alpha: Remove -O1 - we have been using this since 2007, but now it looks the other way round, "make check" fails on sparc with -O1, but works with -O2. * kfreebsd-*: Ignore testsuite failures until we resolve the plperl failures, see #704802. -- Christoph Berg <email address hidden> Fri, 31 May 2013 16:34:34 -0700
Superseded in experimental-release |
postgresql-9.3 (9.3~beta1-2) experimental; urgency=low * Update watch file for 9.3. * 64-pg_upgrade-sockdir: If cwd is too long to use as socketdir in pg_upgrade, fall back to /tmp. (A Unix socket path must not be longer than 107 chars.) -- Christoph Berg <email address hidden> Mon, 13 May 2013 23:09:44 -0700
Superseded in experimental-release |
postgresql-9.3 (9.3~beta1-1) experimental; urgency=low [ Christoph Berg ] * Update for 9.3. Packaging based on 9.2 branch. * Remove 03-python-includedirs.patch, implemented upstream. * libpq5.symbols: Add new symbols: PQconninfo, lo_lseek64, lo_tell64, lo_truncate64. * debian/rules: Remove the temporary patches from pg_regress, and teach pg_regress to support unix socket dirs in --host. * debian/rules: Use "make check-world" to run the regression tests. Thanks to Peter Eisentraut for the suggestion. * 50-per-version-dirs.patch: Use @MAJORVERSION@ instead of a fixed version. * 61-extra_regress_opts: Add EXTRA_REGRESS_OPTS in Makefile.global(.in). * 62-pg_upgrade-test-in-tmp: Hardcode /tmp in pg_upgrade's test.sh. * 63-pg_upgrade-test-bindir: Pass PSQLDIR to the pg_regress call. * postgresql-9.3.install: Add pg_xlogdump. * postgresql-client-9.3.install: Add pg_isready. * libpq-dev.install: Add usr/lib/libpgcommon.a. * libpq-dev.install, libecpg-dev.install: Add pkgconfig files. * postgresql-contrib-9.3.install: Add usr/lib/postgresql/9.3/lib/postgres_fdw.so. [ Martin Pitt ] * Bump p-common dependency to >= 142, to ensure compatibility with 9.3, particularly for upgrades. -- Martin Pitt <email address hidden> Wed, 08 May 2013 05:39:52 +0200
1 → 15 of 15 results | First • Previous • Next • Last |