- 06 2月, 2013 1 次提交
-
-
由 Alvaro Herrera 提交于
The wording changes applied in 0ac5ad51 were universally disliked. Per gripe from Andrew Dunstan
-
- 05 2月, 2013 3 次提交
-
-
由 Tom Lane 提交于
This function was misdeclared to take cstring when it should take internal. This at least allows crashing the server, and in principle an attacker might be able to use the function to examine the contents of server memory. The correct fix is to adjust the system catalog contents (and fix the regression tests that should have caught this but failed to). However, asking users to correct the catalog contents in existing installations is a pain, so as a band-aid fix for the back branches, install a check in enum_recv() to make it throw error if called with a cstring argument. We will later revert this in HEAD in favor of correcting the catalogs. Our thanks to Sumit Soni (via Secunia SVCRP) for reporting this issue. Security: CVE-2013-0255
-
由 Tom Lane 提交于
-
由 Simon Riggs 提交于
Revert commit 84725aa5
-
- 04 2月, 2013 2 次提交
-
-
由 Simon Riggs 提交于
If walsender has xmin of standby then ensure we reset the value to 0 when we change from hot_standby_feedback=on to hot_standby_feedback=off.
-
由 Tom Lane 提交于
This patch changes pg_get_viewdef() and allied functions so that PRETTY_INDENT processing is always enabled. Per discussion, only the PRETTY_PAREN processing (that is, stripping of "unnecessary" parentheses) poses any real forward-compatibility risk, so we may as well make dump output look as nice as we safely can. Also, set the default wrap length to zero (i.e, wrap after each SELECT or FROM list item), since there's no very principled argument for the former default of 80-column wrapping, and most people seem to agree this way looks better. Marko Tiikkaja, reviewed by Jeevan Chalke, further hacking by Tom Lane
-
- 03 2月, 2013 5 次提交
-
-
由 Peter Eisentraut 提交于
This is intended so that say plpy.debug(rv) prints something useful for debugging query execution results. reviewed by Steve Singer
-
由 Tom Lane 提交于
This eases manipulation of query results in psql scripts. Pavel Stehule, reviewed by Piyush Newe, Shigeru Hanada, and Tom Lane
-
由 Tom Lane 提交于
In the previous coding, psql's state variable saying that output should go to a file was only reset after successful completion of a query returning tuples. Thus for example, regression=# select 1/0 regression-# \g somefile ERROR: division by zero regression=# select 1/2; regression=# ... huh, I wonder where that output went. Even more oddly, the state was not reset even if it's the file that's causing the failure: regression=# select 1/2 \g /foo /foo: Permission denied regression=# select 1/2; /foo: Permission denied regression=# select 1/2; /foo: Permission denied This seems to me not to satisfy the principle of least surprise. \g is certainly not documented in a way that suggests its effects are at all persistent. To fix, adjust the code so that the flag is reset at exit from SendQuery no matter what happened. Noted while reviewing the \gset patch, which had comparable issues. Arguably this is a bug fix, but I'll refrain from back-patching for now.
-
由 Simon Riggs 提交于
Following bug analysis of #7819 by Tom Lane
-
由 Bruce Momjian 提交于
Per suggestions from Noah and Tom.
-
- 02 2月, 2013 2 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Alvaro Herrera 提交于
This way, they can be used by frontend and backend code. We already supported that, but doing it this way allows us to mix true frontend files with backend files compiled in frontend environment. Author: Andres Freund
-
- 01 2月, 2013 9 次提交
-
-
由 Alvaro Herrera 提交于
The original code used freeze_min_age instead of freeze_table_age. The main consequence of this mistake is that lowering freeze_min_age would cause full-table scans to occur much more frequently, which causes serious issues because the number of writes required is much larger. That feature (freeze_min_age) is supposed to affect only how soon tuples are frozen; some pages should still be skipped due to the visibility map. Backpatch to 8.4, where the freeze_table_age feature was introduced. Report and patch from Andres Freund
-
由 Alvaro Herrera 提交于
Failing to do this results in almost all updates to system catalogs being non-HOT updates, because the OID column would differ (not having been set for the new tuple), which is an indexed column. While at it, make sure to set the tableoid early in both old and new tuples as well. This isn't of much consequence, since that column is seldom (never?) indexed. Report and patch from Andres Freund.
-
由 Peter Eisentraut 提交于
This is specified in the SQL standard. The CREATE RECURSIVE VIEW specification is transformed into a normal CREATE VIEW statement with a WITH RECURSIVE clause. reviewed by Abhijit Menon-Sen and Stephen Frost
-
由 Peter Eisentraut 提交于
Some constification was added in the Tcl APIs, so add the modifiers in PL/Tcl as well.
-
由 Alvaro Herrera 提交于
We must only set the bit(s) for the strongest lock held in the tuple; otherwise, a multixact containing members with exclusive lock and key-share lock will behave as though only a share lock is held. This bug was introduced in commit 0ac5ad51, somewhere along development, when we allowed a singleton FOR SHARE lock to be implemented without a MultiXact by using a multi-bit pattern. I overlooked that GetMultiXactIdHintBits() needed to be tweaked as well. Previously, we could have the bits for FOR KEY SHARE and FOR UPDATE simultaneously set and it wouldn't cause a problem. Per report from digoal@126.com
-
由 Alvaro Herrera 提交于
Per report from digoal@126.com
-
由 Bruce Momjian 提交于
Mention it might be necessary to modify postgresql.conf in the new cluster to match the old cluster. Backpatch to 9.2. Suggested by user.
-
由 Simon Riggs 提交于
Previous patch to skip checkpoints at end of recovery didn't correctly perform crash recovery, fumbling the timeline switch. Now we record the minRecoveryPointTLI of the newly selected timeline, so that we crash recover to the correct timeline. Bug report from Fujii Masao, investigated by me.
-
由 Tom Lane 提交于
It's not sensible for an interval that's used as a time zone value to be larger than a day. When we changed the interval type to contain a separate day field, check_timezone() was adjusted to reject nonzero day values, but timetz_izone(), timestamp_izone(), and timestamptz_izone() evidently were overlooked. While at it, make the error messages for these three cases consistent.
-
- 31 1月, 2013 5 次提交
-
-
由 Magnus Hagander 提交于
This ensure the version number increases over time. The first three digits in the version number is still set to the actual PostgreSQL version number, but the last one is intended to be an ever increasing build number, which previosly failed when it changed between 1, 2 and 3 digits long values. Noted by Deepak
-
由 Tatsuo Ishii 提交于
The new option specifies length of aggregation interval (in seconds). May be used only together with -l. With this option, the log contains per-interval summary (number of transactions, min/max latency and two additional fields useful for variance estimation). Patch contributed by Tomas Vondra, reviewed by Pavel Stehule. Slight change by Tatsuo Ishii, suggested by Robert Hass to emit an error message indicating that the option is not currently supported on Windows.
-
由 Tom Lane 提交于
There may once have been a reason to violate modularity like that, but it doesn't appear that there is anymore.
-
由 Tom Lane 提交于
exec_simple_check_plan and exec_eval_simple_expr attempted to call GetCachedPlan directly. This meant that if an error was thrown during planning, the resulting context traceback would not include the line normally contributed by _SPI_error_callback. This is already inconsistent, but just to be really odd, a re-execution of the very same expression *would* show the additional context line, because we'd already have cached the plan and marked the expression as non-simple. The problem is easy to demonstrate in 9.2 and HEAD because planning of a cached plan doesn't occur at all until GetCachedPlan is done. In earlier versions, it could only be an issue if initial planning had succeeded, then a replan was forced (already somewhat improbable for a simple expression), and the replan attempt failed. Since the issue is mainly cosmetic in older branches anyway, it doesn't seem worth the risk of trying to fix it there. It is worth fixing in 9.2 since the instability of the context printout can affect the results of GET STACKED DIAGNOSTICS, as per a recent discussion on pgsql-novice. To fix, introduce a SPI function that wraps GetCachedPlan while installing the correct callback function. Use this instead of calling GetCachedPlan directly from plpgsql. Also introduce a wrapper function for extracting a SPI plan's CachedPlanSource list. This lets us stop including spi_priv.h in pl_exec.c, which was never a very good idea from a modularity standpoint. In passing, fix a similar inconsistency that could occur in SPI_cursor_open, which was also calling GetCachedPlan without setting up a context callback.
-
由 Tom Lane 提交于
Such cases should work, but the grammar failed to accept them because of our ancient precedence hacks to convince bison that extra parentheses around a sub-SELECT in an expression are unambiguous. (Formally, they *are* ambiguous, but we don't especially care whether they're treated as part of the sub-SELECT or part of the expression. Bison cares, though.) Fix by adding a redundant-looking production for this case. This is a fine example of why fixing shift/reduce conflicts via precedence declarations is more dangerous than it looks: you can easily cause the parser to reject cases that should work. This has been wrong since commit 3db4056e or maybe before, and apparently some people have been working around it by inserting no-op casts. That method introduces a dump/reload hazard, as illustrated in bug #7838 from Jan Mate. Hence, back-patch to all active branches.
-
- 30 1月, 2013 3 次提交
-
-
由 Peter Eisentraut 提交于
By setting the environment variable PG_REGRESS_DIFF_OPTS, custom diff options can be passed. reviewed by Jeevan Chalke
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
This patch addresses the problem that applications currently have to extract object names from possibly-localized textual error messages, if they want to know for example which index caused a UNIQUE_VIOLATION failure. It adds new error message fields to the wire protocol, which can carry the name of a table, table column, data type, or constraint associated with the error. (Since the protocol spec has always instructed clients to ignore unrecognized field types, this should not create any compatibility problem.) Support for providing these new fields has been added to just a limited set of error reports (mainly, those in the "integrity constraint violation" SQLSTATE class), but we will doubtless add them to more calls in future. Pavel Stehule, reviewed and extensively revised by Peter Geoghegan, with additional hacking by Tom Lane.
-
- 29 1月, 2013 5 次提交
-
-
由 Heikki Linnakangas 提交于
Beyond 21474, the number of accounts exceed the range for int4. Change the initialization code to use bigint for account id columns when scale is large enough, and switch to using int64s for the variables in pgbench code. The threshold where we switch to bigints is set at 20000, because that's easier to remember and document than 21474, and ensures that there is some headroom when int4s are used. Greg Smith, with various changes by Euler Taveira de Oliveira, Gurjeet Singh and Satoshi Nagayasu.
-
由 Heikki Linnakangas 提交于
touched any temporary tables. We could try harder, and keep track of whether we've inserted to any temp tables, rather than accessed them, and which temp tables have been inserted to. But this is dead simple, and already covers many interesting scenarios.
-
由 Simon Riggs 提交于
pg_ctl promote -m fast will skip the checkpoint at end of recovery so that we can achieve very fast failover when the apply delay is low. Write new WAL record XLOG_END_OF_RECOVERY to allow us to switch timeline correctly for downstream log readers. If we skip synchronous end of recovery checkpoint we request a normal spread checkpoint so that the window of re-recovery is low. Simon Riggs and Kyotaro Horiguchi, with input from Fujii Masao. Review by Heikki Linnakangas
-
由 Alvaro Herrera 提交于
Give away ownership of shared objects (databases, tablespaces) along with local objects, per original code intention. Try to make the documentation clearer, too. Per discussion about DROP OWNED's brokenness, in bug #7748. This is not backpatched because it'd require some refactoring of the ALTER/SET OWNER code for databases and tablespaces.
-
由 Alvaro Herrera 提交于
My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb0 not only misstated that it applied to REASSIGN OWNED (which it did not affect), but it also failed to fix the problems fully, because I didn't test the case of owned shared objects. Thus I created a new bug, reported by Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a not-for-user-consumption error message. The code would attempt to drop the database, which not only fails to work because the underlying code does not support that, but is a pretty dangerous and undesirable thing to be doing as well. This patch fixes that bug by having DROP OWNED only attempt to process shared objects when grants on them are found, ignoring ownership. Backpatch to 8.3, which is as far as the previous bug was backpatched.
-
- 28 1月, 2013 1 次提交
-
-
由 Heikki Linnakangas 提交于
If a PL/Python function raises an SPIError (or one if its subclasses) directly with python's raise statement, treat it the same as an SPIError generated internally. In particular, if the user sets the sqlstate attribute, preserve that. Oskari Saarenmaa and Jan Urbański, reviewed by Karl O. Pinc.
-
- 27 1月, 2013 4 次提交
-
-
由 Michael Meskes 提交于
Bug reported and fixed by Chen Huajun <chenhj@cn.fujitsu.com>.
-
由 Tom Lane 提交于
The SQL standard does not have general functions-in-FROM, but it does allow UNNEST() there (see the <collection derived table> production), and the semantics of that are defined to include lateral references. So spec compliance requires allowing lateral references within UNNEST() even without an explicit LATERAL keyword. Rather than making UNNEST() a special case, it seems best to extend this flexibility to any function-in-FROM. We'll still allow LATERAL to be written explicitly for clarity's sake, but it's now a noise word in this context. In theory this change could result in a change in behavior of existing queries, by allowing what had been an outer reference in a function-in-FROM to be captured by an earlier FROM-item at the same level. However, all pre-9.3 PG releases have a bug that causes them to match variable references to earlier FROM-items in preference to outer references (and then throw an error). So no previously-working query could contain the type of ambiguity that would risk a change of behavior. Per a suggestion from Andrew Gierth, though I didn't use his patch.
-
由 Bruce Momjian 提交于
DROP IF EXISTS with a missing schema in commit 7e2322df applies not only to tables, but to DROP IF EXISTS with missing schemas for indexes, views, sequences, and foreign tables. Yeah!
-
由 Bruce Momjian 提交于
Also, commit 7e2322df affected DROP TABLE IF EXISTS, not CREATE TABLE IF EXISTS.
-