aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* MSVC: Process Makefile line continuations more like "make" does.Noah Misch2014-07-14
| | | | | | | | Unlike "make" itself, the MSVC build process recognized a continuation even with whitespace after the backslash. (Due to a typo, some code sites accepted the letter "s" instead of whitespace). Also, it would consume any number of newlines following a single backslash. This is mere cleanup; those behaviors were unlikely to cause bugs.
* MSVC: Recognize PGFILEDESC in contrib and conversion_procs modules.Noah Misch2014-07-14
| | | | | | | Achieve this by consistently using four-argument Solution::AddProject() calls. Remove ad hoc Makefile parsing made redundant by doing that. Michael Paquier and Noah Misch, reviewed by MauMau.
* Fix warnings added in 8d9a0e85bd6ab4fe5268a1d759a787f72ff9333e.Noah Misch2014-07-14
|
* Prevent bitmap heap scans from showing unnecessary block info in EXPLAIN ↵Fujii Masao2014-07-14
| | | | | | | | | | | | | | ANALYZE. EXPLAIN ANALYZE shows the information of the numbers of exact/lossy blocks which bitmap heap scan processes. But, previously, when those numbers were both zero, it displayed only the prefix "Heap Blocks:" in TEXT output format. This is strange and would confuse the users. So this commit suppresses such unnecessary information. Backpatch to 9.4 where EXPLAIN ANALYZE was changed so that such information was displayed. Etsuro Fujita
* Support --with-extra-version equivalent functionality in MSVC buildMagnus Hagander2014-07-12
| | | | | | | Adds a configuration parameter, extraver, that is appended to the version number when built. Michael Paquier, reviewed by Muhammad Asif Naeem
* Minimal psql tab completion support for SET search_path.Andres Freund2014-07-12
| | | | | | | | | | | Complete SET search_path = ... to non-temporary and non-toast schemas. Since there pretty much is no use case to add those to the search path and there can be many it's helpful to exclude them. It'd be nicer to complete multiple search path elements, but that's not easy. Jeff Janes
* Fix decoding of consecutive MULTI_INSERTs emitted by one heap_multi_insert().Andres Freund2014-07-12
| | | | | | | | | | | | | | | | | | | Commit 1b86c81d2d fixed the decoding of toasted columns for the rows contained in one xl_heap_multi_insert record. But that's not actually enough, because heap_multi_insert() will actually first toast all passed in rows and then emit several *_multi_insert records; one for each page it fills with tuples. Add a XLOG_HEAP_LAST_MULTI_INSERT flag which is set in xl_heap_multi_insert->flag denoting that this multi_insert record is the last emitted by one heap_multi_insert() call. Then use that flag in decode.c to only set clear_toast_afterwards in the right situation. Expand the number of rows inserted via COPY in the corresponding regression test to make sure that more than one heap page is filled with tuples by one heap_multi_insert() call. Backpatch to 9.4 like the previous commit.
* Add autocompletion of locale keywords for CREATE DATABASEMagnus Hagander2014-07-12
| | | | | Adds support for autocomplete of LC_COLLATE and LC_CTYPE to the CREATE DATABASE command in psql.
* Fix bug with whole-row references to append subplans.Tom Lane2014-07-11
| | | | | | | | | | | | | | ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source TupleTableSlot just once per query. But if the input is coming from an Append (or, perhaps, other cases?) more than one slot might be returned over the query run. This led to "record type has not been registered" errors when a composite datum was extracted from a non-blessed slot. This bug has been there a long time; I guess it escaped notice because when dealing with subqueries the planner tends to expand whole-row Vars into RowExprs, which don't have the same problem. It is possible to trigger the problem in all active branches, though, as illustrated by the added regression test.
* Fix whitespacePeter Eisentraut2014-07-11
|
* Implement IMPORT FOREIGN SCHEMA.Tom Lane2014-07-10
| | | | | | | | | | | This command provides an automated way to create foreign table definitions that match remote tables, thereby reducing tedium and chances for error. In this patch, we provide the necessary core-server infrastructure and implement the feature fully in the postgres_fdw foreign-data wrapper. Other wrappers will throw a "feature not supported" error until/unless they are updated. Ronan Dunklau and Michael Paquier, additional work by me
* Adjust blank lines around PG_MODULE_MAGIC defines, for consistencyBruce Momjian2014-07-10
| | | | Report by Robert Haas
* Add new ECHO mode 'errors' that displays only failed commands in psql.Fujii Masao2014-07-10
| | | | | | | | | When the psql variable ECHO is set to 'erros', only failed SQL commands are printed to standard error output. Also this patch adds -b option into psql. This is equivalent to setting the variable ECHO to 'errors'. Pavel Stehule, reviewed by Fabrízio de Royes Mello, Samrat Revagade, Kumar Rajeev Rastogi, Abhijit Menon-Sen, and me.
* Fix error hint style.Robert Haas2014-07-09
| | | | Mistake caught by Tom Lane.
* Improve error messages for bytea decoding failures.Robert Haas2014-07-09
| | | | Craig Ringer
* Don't assume a subquery's output is unique if there's a SRF in its tlist.Tom Lane2014-07-08
| | | | | | | | | | | | | While the x output of "select x from t group by x" can be presumed unique, this does not hold for "select x, generate_series(1,10) from t group by x", because we may expand the set-returning function after the grouping step. (Perhaps that should be re-thought; but considering all the other oddities involved with SRFs in targetlists, it seems unlikely we'll change it.) Put a check in query_is_distinct_for() so it's not fooled by such cases. Back-patch to all supported branches. David Rowley
* Fix typo in comment.Fujii Masao2014-07-08
| | | | This typo was accidentally added by recent commit 4cbd128.
* In pg_dump, show server and pg_dump versions with or without --verbose.Tom Lane2014-07-07
| | | | | | | | | We used to print this information only in verbose mode, but it's argued that it's useful enough to print always; one reason being that this provides some documentation about which Postgres versions the dump is meant to reload into. Jing Wang, reviewed by Jeevan Chalke
* Fix typos in comments.Fujii Masao2014-07-07
|
* Remove swpb-based spinlock implementation for ARMv5 and earlier.Robert Haas2014-07-06
| | | | | | | | | | | | | | Per recent analysis by Andres Freund, this implementation is in fact unsafe, because ARMv5 has weak memory ordering, which means tha the CPU could move loads or stores across the volatile store performed by the default S_UNLOCK. We could try to fix this, but have no ARMv5 hardware to test on, so removing support seems better. We can still support ARMv5 systems on GCC versions new enough to have built-in atomics support for this platform, and can also re-add support for the old way if someone has hardware that can be used to test a fix. However, since the requirement to use a relatively-new GCC hasn't been an issue for ARMv6 or ARMv7, which lack the swpb instruction altogether, perhaps it won't be an issue for ARMv5 either.
* Fix decoding of MULTI_INSERTs when rows other than the last are toasted.Andres Freund2014-07-06
| | | | | | | | | | | | | | | | | | | | | | | When decoding the results of a HEAP2_MULTI_INSERT (currently only generated by COPY FROM) toast columns for all but the last tuple weren't replaced by their actual contents before being handed to the output plugin. The reassembled toast datums where disregarded after every REORDER_BUFFER_CHANGE_(INSERT|UPDATE|DELETE) which is correct for plain inserts, updates, deletes, but not multi inserts - there we generate several REORDER_BUFFER_CHANGE_INSERTs for a single xl_heap_multi_insert record. To solve the problem add a clear_toast_afterwards boolean to ReorderBufferChange's union member that's used by modifications. All row changes but multi_inserts always set that to true, but multi_insert sets it only for the last change generated. Add a regression test covering decoding of multi_inserts - there was none at all before. Backpatch to 9.4 where logical decoding was introduced. Bug found by Petr Jelinek.
* Consistently pass an "unsigned char" to ctype.h functions.Noah Misch2014-07-06
| | | | | | The isxdigit() calls relied on undefined behavior. The isascii() call was well-defined, but our prevailing style is to include the cast. Back-patch to 9.4, where the isxdigit() calls were introduced.
* Remove dead typeStruct variable from plpy_spi.c.Kevin Grittner2014-07-05
| | | | Left behind by 8b6010b8350a1756cd85595705971df81b5ffc07.
* Fix double-free bug of WAL streaming buffer in pg_receivexlog.Fujii Masao2014-07-04
| | | | This bug was introduced while refactoring in commit 74cbe96.
* Refactor pg_receivexlog main loop code, for readability.Fujii Masao2014-07-04
| | | | | | | | Previously the source codes for receiving the data and for polling the socket were included in pg_receivexlog main loop. This commit splits out them as separate functions. This is useful for improving the readability of main loop code and making the future pg_receivexlog-related patch simpler.
* Don't cache per-group context across the whole query in orderedsetaggs.c.Tom Lane2014-07-03
| | | | | | | | | | | Although nodeAgg.c currently uses the same per-group memory context for all groups of a query, that might change in future. Avoid assuming it. This costs us an extra AggCheckCallContext() call per group, but that's pretty cheap and is probably good from a safety standpoint anyway. Back-patch to 9.4 in case any third-party code copies this logic. Andrew Gierth
* Redesign API presented by nodeAgg.c for ordered-set and similar aggregates.Tom Lane2014-07-03
| | | | | | | | | | | | | The previous design exposed the input and output ExprContexts of the Agg plan node, but work on grouping sets has suggested that we'll regret doing that. Instead provide more narrowly-defined APIs that can be implemented in multiple ways, namely a way to get a short-term memory context and a way to register an aggregate shutdown callback. Back-patch to 9.4 where the bad APIs were introduced, since we don't want third-party code using these APIs and then having to change in 9.5. Andrew Gierth
* Improve support for composite types in PL/Python.Tom Lane2014-07-03
| | | | | | | | | | | | | | | Allow PL/Python functions to return arrays of composite types. Also, fix the restriction that plpy.prepare/plpy.execute couldn't handle query parameters or result columns of composite types. In passing, adopt a saner arrangement for where to release the tupledesc reference counts acquired via lookup_rowtype_tupdesc. The callers of PLyObject_ToCompositeDatum were doing the lookups, but then the releases happened somewhere down inside subroutines of PLyObject_ToCompositeDatum, which is bizarre and bug-prone. Instead release in the same function that acquires the refcount. Ed Behn and Ronan Dunklau, reviewed by Abhijit Menon-Sen
* Use a separate temporary directory for the Unix-domain socketPeter Eisentraut2014-07-02
| | | | | | | Creating the Unix-domain socket in the build directory can run into name-length limitations. Therefore, create the socket file in the default temporary directory of the operating system. Keep the temporary data directory etc. in the build tree.
* Support vpath builds in TAP testsPeter Eisentraut2014-07-02
|
* Smooth reporting of commit/rollback statistics.Kevin Grittner2014-07-02
| | | | | | | | | | | | | | | | | | | | If a connection committed or rolled back any transactions within a PGSTAT_STAT_INTERVAL pacing interval without accessing any tables, the reporting of those statistics would be held up until the connection closed or until it ended a PGSTAT_STAT_INTERVAL interval in which it had accessed a table. This could result in under- reporting of transactions for an extended period, followed by a spike in reported transactions. While this is arguably a bug, the impact is minimal, primarily affecting, and being affected by, monitoring software. It might cause more confusion than benefit to change the existing behavior in released stable branches, so apply only to master and the 9.4 beta. Gurjeet Singh, with review and editing by Kevin Grittner, incorporating suggested changes from Abhijit Menon-Sen and Tom Lane.
* pg_upgrade: preserve database and relation minmxid valuesBruce Momjian2014-07-02
| | | | | | | | | Also set these values for pre-9.3 old clusters that don't have values to preserve. Analysis by Alvaro Backpatch through 9.3
* Rename logical decoding's pg_llog directory to pg_logical.Andres Freund2014-07-02
| | | | | | | | | | | | | | | The old name wasn't very descriptive as of actual contents of the directory, which are historical snapshots in the snapshots/ subdirectory and mappingdata for rewritten tuples in mappings/. There's been a fair amount of discussion what would be a good name. I'm settling for pg_logical because it's likely that further data around logical decoding and replication will need saving in the future. Also add the missing entry for the directory into storage.sgml's list of PGDATA contents. Bumps catversion as the data directories won't be compatible.
* Add some errdetail to checkRuleResultList().Tom Lane2014-07-02
| | | | | | | | | | | | | | | | | This function wasn't originally thought to be really user-facing, because converting a table to a view isn't something we expect people to do manually. So not all that much effort was spent on the error messages; in particular, while the code will complain that you got the column types wrong it won't say exactly what they are. But since we repurposed the code to also check compatibility of rule RETURNING lists, it's definitely user-facing. It now seems worthwhile to add errdetail messages showing exactly what the conflict is when there's a mismatch of column names or types. This is prompted by bug #10836 from Matthias Raffelsieper, which might have been forestalled if the error message had reported the wrong column type as being "record". Back-patch to 9.4, but not into older branches where the set of translatable error strings is supposed to be stable.
* Prevent psql from issuing BEGIN before ALTER SYSTEM when AUTOCOMMIT is off.Fujii Masao2014-07-02
| | | | | | | | | | | | | The autocommit-off mode works by issuing an implicit BEGIN just before any command that is not already in a transaction block and is not itself a BEGIN or other transaction-control command, nor a command that cannot be executed inside a transaction block. This commit prevents psql from issuing such an implicit BEGIN before ALTER SYSTEM because it's not allowed inside a transaction block. Backpatch to 9.4 where ALTER SYSTEM was added. Report by Feike Steenbergen
* Allow CREATE/ALTER DATABASE to manipulate datistemplate and datallowconn.Tom Lane2014-07-01
| | | | | | | | | | | Historically these database properties could be manipulated only by manually updating pg_database, which is error-prone and only possible for superusers. But there seems no good reason not to allow database owners to set them for their databases, so invent CREATE/ALTER DATABASE options to do that. Adjust a couple of places that were doing it the hard way to use the commands instead. Vik Fearing, reviewed by Pavel Stehule
* Refactor CREATE/ALTER DATABASE syntax so options need not be keywords.Tom Lane2014-07-01
| | | | | | | | | | | | | Most of the existing option names are keywords anyway, but we can get rid of LC_COLLATE and LC_CTYPE as keywords known to the lexer/grammar. This immediately reduces the size of the grammar tables by about 8KB, and will save more when we add additional CREATE/ALTER DATABASE options in future. A side effect of the implementation is that the CONNECTION LIMIT option can now also be spelled CONNECTION_LIMIT. We choose not to document this, however. Vik Fearing, based on a suggestion by me; reviewed by Pavel Stehule
* Remove some useless code in the configure script.Tom Lane2014-07-01
| | | | | | | | | | | | Almost ten years ago, commit e48322a6d6cfce1ec52ab303441df329ddbc04d1 broke the logic in ACX_PTHREAD by looping through all the possible flags rather than stopping with the first one that would work. This meant that $acx_pthread_ok was no longer meaningful after the loop; it would usually be "no", whether or not we'd found working thread flags. The reason nobody noticed is that Postgres doesn't actually use any of the symbols set up by the code after the loop. Rather than complicate things some more to make it work as designed, let's just remove all that dead code, and thereby save a few cycles in each configure run.
* Avoid copying index tuples when building an index.Robert Haas2014-07-01
| | | | | | | | | | | | The previous code, perhaps out of concern for avoid memory leaks, formed the tuple in one memory context and then copied it to another memory context. However, this doesn't appear to be necessary, since index_form_tuple and the functions it calls take precautions against leaking memory. In my testing, building the tuple directly inside the sort context shaves several percent off the index build time. Rearrange things so we do that. Patch by me. Review by Amit Kapila, Tom Lane, Andres Freund.
* Check interrupts during logical decoding more frequently.Andres Freund2014-06-30
| | | | | | | | | | | | | | | When reading large amounts of preexisting WAL during logical decoding using the SQL interface we possibly could fail to check interrupts in due time. Similarly the same could happen on systems with a very high WAL volume while creating a new logical replication slot, independent of the used interface. Previously these checks where only performed in xlogreader's read_page callbacks, while waiting for new WAL to be produced. That's not sufficient though, if there's never a need to wait. Walsender's send loop already contains a interrupt check. Backpatch to 9.4 where the logical decoding feature was introduced.
* Fix and enhance the assertion of no palloc's in a critical section.Heikki Linnakangas2014-06-30
| | | | | | | | | | | | The assertion failed if WAL_DEBUG or LWLOCK_STATS was enabled; fix that by using separate memory contexts for the allocations made within those code blocks. This patch introduces a mechanism for marking any memory context as allowed in a critical section. Previously ErrorContext was exempt as a special case. Instead of a blanket exception of the checkpointer process, only exempt the memory context used for the pending ops hash table.
* Remove use_json_as_text options from json_to_record/json_populate_record.Tom Lane2014-06-29
| | | | | | | | | | | | | | | | The "false" case was really quite useless since all it did was to throw an error; a definition not helped in the least by making it the default. Instead let's just have the "true" case, which emits nested objects and arrays in JSON syntax. We might later want to provide the ability to emit sub-objects in Postgres record or array syntax, but we'd be best off to drive that off a check of the target field datatype, not a separate argument. For the functions newly added in 9.4, we can just remove the flag arguments outright. We can't do that for json_populate_record[set], which already existed in 9.3, but we can ignore the argument and always behave as if it were "true". It helps that the flag arguments were optional and not documented in any useful fashion anyway.
* Add cluster_name GUC which is included in process titles if set.Andres Freund2014-06-29
| | | | | | | | | | | | | | | | | | When running several postgres clusters on one OS instance it's often inconveniently hard to identify which "postgres" process belongs to which postgres instance. Add the cluster_name GUC, whose value will be included as part of the process titles if set. With that processes can more easily identified using tools like 'ps'. To avoid problems with encoding mismatches between postgresql.conf, consoles, and individual databases replace non-ASCII chars in the name with question marks. The length is limited to NAMEDATALEN to make it less likely to truncate important information at the end of the status. Thomas Munro, with some adjustments by me and review by a host of people.
* Remove Alpha and Tru64 support.Andres Freund2014-06-28
| | | | | | | | | | | | | Support for running postgres on Alpha hasn't been tested for a long while. Due to Alpha's uniquely lax cache coherency model it's a hard to develop for platform (especially blindly!) and thought to be unlikely to currently work correctly. As Alpha is the only supported architecture for Tru64 drop support for it as well. Tru64's support has ended 2012 and it has been in maintenance-only mode for much longer. Also remove stray references to __ksr__ and ultrix defines.
* Allow pushdown of WHERE quals into subqueries with window functions.Tom Lane2014-06-27
| | | | | | | | | | | | | | | | | | | | | | | | We can allow this even without any specific knowledge of the semantics of the window function, so long as pushed-down quals will either accept every row in a given window partition, or reject every such row. Because window functions act only within a partition, such a case can't result in changing the window functions' outputs for any surviving row. Eliminating entire partitions in this way obviously can reduce the cost of the window-function computations substantially. The fly in the ointment is that it's hard to be entirely sure whether this is true for an arbitrary qual condition. This patch allows pushdown if (a) the qual references only partitioning columns, and (b) the qual contains no volatile functions. We are at risk of incorrect results if the qual can produce different answers for values that the partitioning equality operator sees as equal. While it's not hard to invent cases for which that can happen, it seems to seldom be a problem in practice, since no one has complained about a similar assumption that we've had for many years with respect to DISTINCT. The potential performance gains seem to be worth the risk. David Rowley, reviewed by Vik Fearing; some credit is due also to Thomas Mayer who did considerable preliminary investigation.
* Have multixact be truncated by checkpoint, not vacuumAlvaro Herrera2014-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of truncating pg_multixact at vacuum time, do it only at checkpoint time. The reason for doing it this way is twofold: first, we want it to delete only segments that we're certain will not be required if there's a crash immediately after the removal; and second, we want to do it relatively often so that older files are not left behind if there's an untimely crash. Per my proposal in http://www.postgresql.org/message-id/20140626044519.GJ7340@eldon.alvh.no-ip.org we now execute the truncation in the checkpointer process rather than as part of vacuum. Vacuum is in only charge of maintaining in shared memory the value to which it's possible to truncate the files; that value is stored as part of checkpoints also, and so upon recovery we can reuse the same value to re-execute truncate and reset the oldest-value-still-safe-to-use to one known to remain after truncation. Per bug reported by Jeff Janes in the course of his tests involving bug #8673. While at it, update some comments that hadn't been updated since multixacts were changed. Backpatch to 9.3, where persistency of pg_multixact files was introduced by commit 0ac5ad5134f2.
* Don't allow relminmxid to go backwards during VACUUM FULLAlvaro Herrera2014-06-27
| | | | | | | | | | | | | We were allowing a table's pg_class.relminmxid value to move backwards when heaps were swapped by VACUUM FULL or CLUSTER. There is a similar protection against relfrozenxid going backwards, which we neglected to clone when the multixact stuff was rejiggered by commit 0ac5ad5134f276. Backpatch to 9.3, where relminmxid was introduced. As reported by Heikki in http://www.postgresql.org/message-id/52401AEA.9000608@vmware.com
* Fix broken Assert() introduced by 8e9a16ab8f7f0e58Alvaro Herrera2014-06-27
| | | | | | | | | | | | | | | | Don't assert MultiXactIdIsRunning if the multi came from a tuple that had been share-locked and later copied over to the new cluster by pg_upgrade. Doing that causes an error to be raised unnecessarily: MultiXactIdIsRunning is not open to the possibility that its argument came from a pg_upgraded tuple, and all its other callers are already checking; but such multis cannot, obviously, have transactions still running, so the assert is pointless. Noticed while investigating the bogus pg_multixact/offsets/0000 file left over by pg_upgrade, as reported by Andres Freund in http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de Backpatch to 9.3, as the commit that introduced the buglet.
* Disallow pushing volatile qual expressions down into DISTINCT subqueries.Tom Lane2014-06-27
| | | | | | | | | | | | | | | | A WHERE clause applied to the output of a subquery with DISTINCT should theoretically be applied only once per distinct row; but if we push it into the subquery then it will be evaluated at each row before duplicate elimination occurs. If the qual is volatile this can give rise to observably wrong results, so don't do that. While at it, refactor a little bit to allow subquery_is_pushdown_safe to report more than one kind of restrictive condition without indefinitely expanding its argument list. Although this is a bug fix, it seems unwise to back-patch it into released branches, since it might de-optimize plans for queries that aren't giving any trouble in practice. So apply to 9.4 but not further back.
* Get rid of bogus separate pg_proc entries for json_extract_path operators.Tom Lane2014-06-26
| | | | | | | | | | | | These should not have existed to begin with, but there was apparently some misunderstanding of the purpose of the opr_sanity regression test item that checks for operator implementation functions with their own comments. The idea there is to check for unintentional violations of the rule that operator implementation functions shouldn't be documented separately .... but for these functions, that is in fact what we want, since the variadic option is useful and not accessible via the operator syntax. Get rid of the extra pg_proc entries and fix the regression test and documentation to be explicit about what we're doing here.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-16 04:07:42 +0000