- 04 Apr, 2013 5 commits
-
-
Andrew Dunstan authored
Bug report by David Wheeler, diagnosis assistance from Tom Lane.
-
Bruce Momjian authored
'strdup' the PSQLRC environment variable value before calling a routine that might free() it. Backpatch to 9.2, where the bug first appeared.
-
Heikki Linnakangas authored
Throw an error instead. Backpatch to all supported branches.
-
Andrew Dunstan authored
Dickson S. Guedes
-
Heikki Linnakangas authored
The old formula didn't take into account that each WAL sender process needs a spinlock. We had also already exceeded the fixed number of spinlocks reserved for misc purposes (10). Bump that to 30. Backpatch to 9.0, where WAL senders were introduced. If I counted correctly, 9.0 had exactly 10 predefined spinlocks, and 9.1 exceeded that, but bump the limit in 9.0 too because 10 is uncomfortably close to the edge.
-
- 03 Apr, 2013 3 commits
-
-
Tom Lane authored
The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
-
Tom Lane authored
Laurenz Albe
-
Tom Lane authored
Notice and complain about PQcancel() failures. Also, don't dump core if an error PGresult doesn't contain severity and message subfields, as it might not if it was generated by libpq itself. (We have a longstanding TODO item to improve that, but in the meantime isolationtester had better cope.) I tripped across the latter item while investigating a trouble report on buildfarm member spoonbill. As for the former, there's no evidence that PQcancel failure is actually involved in spoonbill's problem, but it still seems like a bad idea to ignore an error return code.
-
- 01 Apr, 2013 4 commits
-
-
Tom Lane authored
Security: CVE-2013-1899, CVE-2013-1901
-
Tom Lane authored
An oversight in commit e710b65c allowed database names beginning with "-" to be treated as though they were secure command-line switches; and this switch processing occurs before client authentication, so that even an unprivileged remote attacker could exploit the bug, needing only connectivity to the postmaster's port. Assorted exploits for this are possible, some requiring a valid database login, some not. The worst known problem is that the "-r" switch can be invoked to redirect the process's stderr output, so that subsequent error messages will be appended to any file the server can write. This can for example be used to corrupt the server's configuration files, so that it will fail when next restarted. Complete destruction of database tables is also possible. Fix by keeping the database name extracted from a startup packet fully separate from command-line switches, as had already been done with the user name field. The Postgres project thanks Mitsumasa Kondo for discovering this bug, Kyotaro Horiguchi for drafting the fix, and Noah Misch for recognizing the full extent of the danger. Security: CVE-2013-1899
-
Tom Lane authored
The pg_start_backup() and pg_stop_backup() functions checked the privileges of the initially-authenticated user rather than the current user, which is wrong. For example, a user-defined index function could successfully call these functions when executed by ANALYZE within autovacuum. This could allow an attacker with valid but low-privilege database access to interfere with creation of routine backups. Reported and fixed by Noah Misch. Security: CVE-2013-1901
-
Peter Eisentraut authored
This reverts commit 3780fc67. HP-UX didn't like it. There would probably be a way to fix that, but since the net effect of all of this is zero because ecpg ends up using libpq anyway, it's not worth bothering further.
-
- 31 Mar, 2013 5 commits
-
-
Tom Lane authored
-
Tom Lane authored
In commit 0f61d4dd, I added code to copy up column width estimates for each column of a subquery. That code supposed that the subquery couldn't have any output columns that didn't correspond to known columns of the current query level --- which is true when a query is parsed from scratch, but the assumption fails when planning a view that depends on another view that's been redefined (adding output columns) since the upper view was made. This results in an assertion failure or even a crash, as per bug #8025 from lindebg. Remove the Assert and instead skip the column if its resno is out of the expected range.
-
Peter Eisentraut authored
This will hopefully be easier to use than pg_config for users who are already used to the pkg-config interface. It also works better for multi-arch installations. reviewed by Tom Lane
-
Peter Eisentraut authored
It doesn't actually use libpq. But we need to keep libpq in the CPPFLAGS for building, because compatlib uses ecpglib.h which uses libpq-fe.h, but we don't need to refer to libpq for linking. reviewed by Tom Lane
-
Bruce Momjian authored
Now that pg_dump no longer dumps invalid indexes, per commit 683abc73, have pg_upgrade also skip them. Previously pg_upgrade threw an error if invalid indexes existed. Backpatch to 9.2, 9.1, and 9.0 (where pg_upgrade was added to git)
-
- 30 Mar, 2013 4 commits
-
-
Tom Lane authored
The modern incarnation of md.c is by no means specific to magnetic disk technology, but every so often we hear from someone who's misled by the label. Try to clarify that it will work for anything that supports standard filesystem operations. Per suggestion from Andrew Dunstan.
-
Andrew Dunstan authored
Windows sometimes gets upset if we rename a large directory and then try to use the old name quickly, as seen in occasional buildfarm failures. So we avoid that by building the old version in the intended destination in the first place instead of renaming it, similar to the change made for the same reason in commit b7f8465c.
-
Bruce Momjian authored
-
Peter Eisentraut authored
In some parallel make situations, the install-headers target could be called before the installation directories are created by installdirs, causing the installation to fail. Fix that by making install-headers depend on installdirs.
-
- 29 Mar, 2013 5 commits
-
-
Andrew Dunstan authored
-
Andrew Dunstan authored
The JSON parser is converted into a recursive descent parser, and exposed for use by other modules such as extensions. The API provides hooks for all the significant parser event such as the beginning and end of objects and arrays, and providing functions to handle these hooks allows for fairly simple construction of a wide variety of JSON processing functions. A set of new basic processing functions and operators is also added, which use this API, including operations to extract array elements, object fields, get the length of arrays and the set of keys of a field, deconstruct an object into a set of key/value pairs, and create records from JSON objects and arrays of objects. Catalog version bumped. Andrew Dunstan, with some documentation assistance from Merlin Moncure.
-
Tom Lane authored
I changed this in commit fd15dba5, but missed the fact that the SGML documentation of the function specified exactly what it did. Well, one of the two places where it's specified documented that --- probably I looked at the other place and thought nothing needed to be done. Sync the two places where encode() and decode() are described.
-
Tom Lane authored
9.2 uses a kluge representation of "indislive"; we have to account for that when examining pg_index. Simplest solution is to check indisready for 9.0 and 9.1 as well; that's harmless though unnecessary, so it's not worth making a version distinction for. Fixes oversight in commit 683abc73, as noted by Andres Freund.
-
Tom Lane authored
Covers commits through today. Not back-patching into back branches yet, since this is just for people to review in advance.
-
- 28 Mar, 2013 7 commits
-
-
Robert Haas authored
Fixes by me, per griping by Thom Brown.
-
Robert Haas authored
The main change here is to call security_compute_create_name_raw() rather than security_compute_create_raw(). This ups the minimum requirement for libselinux from 2.0.99 to 2.1.10, but it looks like most distributions will have picked that up before 9.3 is out. KaiGai Kohei
-
Tom Lane authored
DST law changes in Chile, Haiti, Morocco, Paraguay, some Russian areas. Historical corrections for numerous places.
-
Tom Lane authored
On older-model gcc, the original coding of UTILITY_BEGIN_QUERY() can draw this error because of multiple assignments to _needCleanup. Rather than mark that variable volatile, we can suppress the warning by arranging to have just one unconditional assignment before PG_TRY.
-
Alvaro Herrera authored
This event takes place just before ddl_command_end, and is fired if and only if at least one object has been dropped by the command. (For instance, DROP TABLE IF EXISTS of a table that does not in fact exist will not lead to such a trigger firing). Commands that drop multiple objects (such as DROP SCHEMA or DROP OWNED BY) will cause a single event to fire. Some firings might be surprising, such as ALTER TABLE DROP COLUMN. The trigger is fired after the drop has taken place, because that has been deemed the safest design, to avoid exposing possibly-inconsistent internal state (system catalogs as well as current transaction) to the user function code. This means that careful tracking of object identification is required during the object removal phase. Like other currently existing events, there is support for tag filtering. To support the new event, add a new pg_event_trigger_dropped_objects() set-returning function, which returns a set of rows comprising the objects affected by the command. This is to be used within the user function code, and is mostly modelled after the recently introduced pg_identify_object() function. Catalog version bumped due to the new function. Dimitri Fontaine and Álvaro Herrera Review by Robert Haas, Tom Lane
-
Simon Riggs authored
-
Simon Riggs authored
-
- 27 Mar, 2013 7 commits
-
-
Tom Lane authored
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do when ssl=on in postgresql.conf), the same pseudo-random state would be inherited by each forked child process. The problem is masked to a considerable extent if the incoming connection uses SSL encryption, but when it does not, identical pseudo-random state is made available to functions like contrib/pgcrypto. The process's PID does get mixed into any requested random output, but on most systems that still only results in 32K or so distinct random sequences available across all Postgres sessions. This might allow an attacker who has database access to guess the results of "secure" operations happening in another session. To fix, forcibly reset the PRNG after fork(). Each child process that has need for random numbers from OpenSSL's generator will thereby be forced to go through OpenSSL's normal initialization sequence, which should provide much greater variability of the sequences. There are other ways we might do this that would be slightly cheaper, but this approach seems the most future-proof against SSL-related code changes. This has been assigned CVE-2013-1900, but since the issue and the patch have already been publicized on pgsql-hackers, there's no point in trying to hide this commit. Back-patch to all supported branches. Marko Kreen
-
Kevin Grittner authored
Commit bc5334d8 accidentally included a second <variablelist> tag for a new list item.
-
Heikki Linnakangas authored
In a heap update, if the old and new tuple were on different pages, and the new page no longer existed (because it was subsequently truncated away by vacuum), heap_xlog_update forgot to release the pin on the old buffer. This bug was introduced by the "Fix multiple problems in WAL replay" patch, commit 3bbf668d (on master branch). With full_page_writes=off, this triggered an "incorrect local pin count" error later in replay, if the old page was vacuumed. This fixes bug #7969, reported by Yunong Xiao. Backpatch to 9.0, like the commit that introduced this bug.
-
Simon Riggs authored
Remove comment questioning whether this is necessary for DataDir. From buildfarm failures on Windows.
-
Heikki Linnakangas authored
Move functions used only by pg_dump and pg_restore from dumputils.c to a new file, pg_backup_utils.c. dumputils.c is linked into psql and some programs in bin/scripts, so it seems good to keep it slim. The parallel functionality is moved to parallel.c, as is exit_horribly, because the interesting code in exit_horribly is parallel-related. This refactoring gets rid of the on_exit_msg_func function pointer. It was problematic, because a modern gcc version with -Wmissing-format-attribute complained if it wasn't marked with PF_PRINTF_ATTRIBUTE, but the ancient gcc version that Tom Lane's old HP-UX box has didn't accept that attribute on a function pointer, and gave an error. We still use a similar function pointer trick for getLocalPQBuffer() function, to use a thread-local version of that in parallel mode on Windows, but that dodges the problem because it doesn't take printf-like arguments.
-
Robert Haas authored
KaiGai Kohei
-
Simon Riggs authored
If required, recovery.conf can now be located outside of the data directory. Server needs read/write permissions on this directory.
-