aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Remove unnecessary use of PROCEDURALPeter Eisentraut2019-02-25
| | | | | | | | | | | Remove some unnecessary, legacy-looking use of the PROCEDURAL keyword before LANGUAGE. We mostly don't use this anymore, so some of these look a bit old. There is still some use in pg_dump, which is harder to remove because it's baked into the archive format, so I'm not touching that. Discussion: https://www.postgresql.org/message-id/2330919b-62d9-29ac-8de3-58c024fdcb96@2ndquadrant.com
* Make release of 2PC identifier and locks consistent in COMMIT PREPAREDMichael Paquier2019-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When preparing a transaction in two-phase commit, a dummy PGPROC entry holding the GID used for the transaction is registered, which gets released once COMMIT PREPARED is run. Prior releasing its shared memory state, all the locks taken in the prepared transaction are released using a dedicated set of callbacks (pgstat and multixact having similar callbacks), which may cause the locks to be released before the GID is set free. Hence, there is a small window where lock conflicts could happen, for example: - Transaction A releases its locks, still holding its GID in shared memory. - Transaction B held a lock which conflicted with locks of transaction A. - Transaction B continues its processing, reusing the same GID as transaction A. - Transaction B fails because of a conflicting GID, already in use by transaction A. This commit changes the shared memory state release so as post-commit callbacks and predicate lock cleanup happen consistently with the shared memory state cleanup for the dummy PGPROC entry. The race window is small and 2PC had this issue from the start, so no backpatch is done. On top if that fixes discussed involved ABI breakages, which are not welcome in stable branches. Reported-by: Oleksii Kliukin, Ildar Musin Diagnosed-by: Oleksii Kliukin, Ildar Musin Author: Michael Paquier Reviewed-by: Masahiko Sawada, Oleksii Kliukin Discussion: https://postgr.es/m/BF9B38A4-2BFF-46E8-BA87-A2D00A8047A6@hintbits.com
* Fix inconsistent out-of-memory error reporting in dsa.c.Thomas Munro2019-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 16be2fd1 introduced the flag DSA_ALLOC_NO_OOM to control whether the DSA allocator would raise an error or return InvalidDsaPointer on failure to allocate. One edge case was not handled correctly: if we fail to allocate an internal "span" object for a large allocation, we would always return InvalidDsaPointer regardless of the flag; a caller not expecting that could then dereference a null pointer. This is a plausible explanation for a one-off report of a segfault. Remove a redundant pair of braces so that all three stanzas that handle DSA_ALLOC_NO_OOM match in style, for visual consistency. While fixing inconsistencies, if FreePageManagerGet() can't supply the pages that our book-keeping says it should be able to supply, then we should always report a FATAL error. Previously we treated that as a regular allocation failure in one code path, but as a FATAL condition in another. Back-patch to 10, where dsa.c landed. Author: Thomas Munro Reported-by: Jakub Glapa Discussion: https://postgr.es/m/CAEepm=2oPqXxyWQ-1o60tpOLrwkw=VpgNXqqF1VN2EyO9zKGQw@mail.gmail.com
* Fix ecpg bugs caused by missing semicolons in the backend grammar.Tom Lane2019-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | The Bison documentation clearly states that a semicolon is required after every grammar rule, and our scripts that generate ecpg's grammar from the backend's implicitly assumed this is true. But it turns out that only ancient versions of Bison actually enforce that. There have been a couple of rules without trailing semicolons in gram.y for some time, and as a consequence, ecpg's grammar was faulty and produced wrong output for the affected statements. To fix, add the missing semis, and add some cross-checks to ecpg's scripts so that they'll bleat if we mess this up again. The cases that were broken were: * "SET variable = DEFAULT" (but not "SET variable TO DEFAULT"), as well as allied syntaxes such as ALTER SYSTEM SET ... DEFAULT. These produced syntactically invalid output that the server would reject. * Multiple type names in DROP TYPE/DOMAIN commands. Only the first type name would be listed in the emitted command. Per report from Daisuke Higuchi. Back-patch to all supported versions. Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905DB51CE@g01jpexmbkw24
* Tolerate EINVAL when calling fsync() on a directory.Thomas Munro2019-02-24
| | | | | | | | | | | Previously, we tolerated EBADF as a way for the operating system to indicate that it doesn't support fsync() on a directory. Tolerate EINVAL too, for older versions of Linux CIFS. Bug #15636. Back-patch all the way. Reported-by: John Klann Discussion: https://postgr.es/m/15636-d380890dafd78fc6@postgresql.org
* Tolerate ENOSYS failure from sync_file_range().Thomas Munro2019-02-24
| | | | | | | | | | | | | | | | | | | | | One unintended consequence of commit 9ccdd7f6 was that Windows WSL users started getting a panic whenever we tried to initiate data flushing with sync_file_range(), because WSL does not implement that system call. Previously, they got a stream of periodic warnings, which was also undesirable but at least ignorable. Prevent the panic by handling ENOSYS specially and skipping the panic promotion with data_sync_elevel(). Also suppress future attempts after the first such failure so that the pre-existing problem of noisy warnings is improved. Back-patch to 9.6 (older branches were not affected in this way by 9ccdd7f6). Author: Thomas Munro and James Sewell Tested-by: James Sewell Reported-by: Bruce Klein Discussion: https://postgr.es/m/CA+mCpegfOUph2U4ZADtQT16dfbkjjYNJL1bSTWErsazaFjQW9A@mail.gmail.com
* Revert "pg_regress: Don't use absolute paths for the diff"Peter Eisentraut2019-02-23
| | | | | | This reverts commit 1995552deb5479a50ec9044f0179f906ff7772e0. Several developers didn't like the new behavior.
* Fix incorrect function reference in comment of twophase.cMichael Paquier2019-02-23
| | | | | | | | The header block of TwoPhaseGetDummyBackendId mentioned incorrectly TwoPhaseGetDummyProc. Reported-by: Oleksii Kliukin Discussion: https://postgr.es/m/D8336E40-BBE1-4954-98BB-7830D3F5CB36@hintbits.com
* Add TAP tests for 2PC post-commit callbacks of multixacts at recoveryMichael Paquier2019-02-23
| | | | | | | | | | | | The current set of TAP tests for two-phase transactions include some coverage for post-commit callbacks of multixact, but it lacked tests for testing the recovery of those callbacks. This commit adds some tests with soft and hard restarts in this case, using transactions which include DDLs. Author: Michael Paquier Reviewed-by: Oleksii Kliukin Discussion: https://postgr.es/m/20190221055431.GO15532@paquier.xyz
* Fix plan created for inherited UPDATE/DELETE with all tables excluded.Tom Lane2019-02-22
| | | | | | | | | | | | | | | | | | | | | | In the case where inheritance_planner() finds that every table has been excluded by constraints, it thought it could get away with making a plan consisting of just a dummy Result node. While certainly there's no updating or deleting to be done, this had two user-visible problems: the plan did not report the correct set of output columns when a RETURNING clause was present, and if there were any statement-level triggers that should be fired, it didn't fire them. Hence, rather than only generating the dummy Result, we need to stick a valid ModifyTable node on top, which requires a tad more effort here. It's been broken this way for as long as inheritance_planner() has known about deleting excluded subplans at all (cf commit 635d42e9c), so back-patch to all supported branches. Amit Langote and Tom Lane, per a report from Petr Fedorov. Discussion: https://postgr.es/m/5da6f0f0-1364-1876-6978-907678f89a3e@phystech.edu
* Report correct name in autovacuum "work items" activityAlvaro Herrera2019-02-22
| | | | | | | | We were reporting the database name instead of the relation name to pg_stat_activity. Repair. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190220185552.GR28750@telsasoft.com
* Add const qualifierPeter Eisentraut2019-02-22
| | | | | | New code introduced in 050710b36964dee7e1b2bf6b5ef00041fd5d2787. The lack of const is not currently a compiler warning, but it's nice to have for consistency with surrounding code.
* Remove duplicate variable declaration in fe-connect.cMichael Paquier2019-02-22
| | | | | | | | The same variables are declared twice when checking if a connection is writable, which is useless. Author: Haribabu Kommi Discussion: https://postgr.es/m/CAJrrPGf=rcALB54w_Tg1_hx3y+cgSWaERY-uYSQzGc3Zt5XN4g@mail.gmail.com
* Fix mark-and-restore-skipping test case to not be a self-join.Tom Lane2019-02-21
| | | | | | | | | There isn't any good reason for this test to be a self-join rather than a join between separate tables, except that it saved a couple of SQL commands for setup. A proposed patch to optimize away self-joins breaks the test, so adjust it to avoid that happening. Discussion: https://postgr.es/m/64486b0b-0404-e39e-322d-0801154901f3@postgrespro.ru
* Move estimate_hashagg_tablesize to selfuncs.c, and widen result to double.Tom Lane2019-02-21
| | | | | | | | | | | | | | | | | It seems to make more sense for this to be in selfuncs.c, since it's largely a statistical-estimation thing, and it's related to other functions like estimate_hash_bucket_stats that are there. While at it, change the result type from Size to double. Perhaps at one point it was impossible for the result to overflow an integer, but I've got no confidence in that proposition anymore. Nothing's actually done with the result except to compare it to a work_mem-based limit, so as long as we don't get an overflow on the way to that comparison, things should be fine even with very large dNumGroups. Code movement proposed by Antonin Houska, type change by me Discussion: https://postgr.es/m/25767.1549359615@localhost
* Hide other user's pg_stat_ssl rowsPeter Eisentraut2019-02-21
| | | | | | | | | | Change pg_stat_ssl so that an unprivileged user can only see their own rows; other rows will be all null. This makes the behavior consistent with pg_stat_activity, where information about where the connection came from is also restricted. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/63117976-d02c-c8e2-3aef-caa31a5ab8d3%402ndquadrant.com
* pg_regress: Don't use absolute paths for the diffPeter Eisentraut2019-02-21
| | | | | | | | | | Don't expand inputfile and outputfile to absolute paths globally, just where needed. In particular, pass them as is to the file name arguments of the diff command, so that we don't see the full absolute path in the diff header, which makes the diff unnecessarily verbose and harder to read. Discussion: https://www.postgresql.org/message-id/0cc82900-c457-1cee-3ab2-7b0f5d215061@2ndquadrant.com
* Move code for managing PartitionDescs into a new file, partdesc.cRobert Haas2019-02-21
| | | | | | | | | | This is similar in spirit to the existing partbounds.c file in the same directory, except that there's a lot less code in the new file created by this commit. Pending work in this area proposes to add a bunch more code related to PartitionDescs, though, and this will give us a good place to put it. Discussion: http://postgr.es/m/CA+TgmoZUwPf_uanjF==gTGBMJrn8uCq52XYvAEorNkLrUdoawg@mail.gmail.com
* Delay lock acquisition for partitions until we route a tuple to them.Robert Haas2019-02-21
| | | | | | | | | | | | | | | | | | Instead of locking all partitions to which we might route a tuple at executor startup, just lock them as we use them. In some cases such a partition might get locked at executor startup anyway because it appears in the query's range table for some other reason, but in other cases this is a bit savings. This changes the order in which partitions are locked in some cases, which might conceivably create deadlock hazards that don't exist today, but per discussion, it seems like such cases should be rare enough that we can neglect them in favor of improving performance. David Rowley, reviewed and tested by Tomas Vondra, Sho Kato, John Naylor, Tom Lane, and me. Discussion: http://postgr.es/m/CAKJS1f-=FnMqmQP6qitkD+xEddxw22ySLP-0xFk3JAqUX2yfMw@mail.gmail.com
* Speed up match_eclasses_to_foreign_key_col() when there are many ECs.Tom Lane2019-02-20
| | | | | | | | | | | | | Check ec_relids before bothering to iterate through the EC members. On a perhaps extreme, but still real-world, query in which match_eclasses_to_foreign_key_col() accounts for the bulk of the planner's runtime, this saves nearly 40% of the runtime. It's a bit of a stopgap fix, but it's simple enough to be back-patched to 9.6 where this code came in; so let's do that. David Rowley Discussion: https://postgr.es/m/6970.1545327857@sss.pgh.pa.us
* Use an unsigned char for bool if we don't use the native bool.Andrew Gierth2019-02-20
| | | | | | | | | | On (rare) platforms where sizeof(bool) > 1, we need to use our own bool, but imported c99 code (such as Ryu) may want to use bool values as array subscripts, which elicits warnings if bool is defined as char. Using unsigned char instead should work just as well for our purposes, and avoid such warnings. Per buildfarm members prariedog and locust.
* Improve planner's understanding of strictness of type coercions.Tom Lane2019-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | PG type coercions are generally strict, ie a NULL input must produce a NULL output (or, in domain cases, possibly an error). The planner's understanding of that was a bit incomplete though, so improve it: * Teach contain_nonstrict_functions() that CoerceViaIO can always be considered strict. Previously it believed that only if the underlying I/O functions were marked strict, which is often but not always true. * Teach clause_is_strict_for() that CoerceViaIO, ArrayCoerceExpr, ConvertRowtypeExpr, CoerceToDomain can all be considered strict. Previously it knew nothing about any of them. The main user-visible impact of this is that IS NOT NULL predicates can be proven to hold from expressions involving casts in more cases than before, allowing partial indexes with such predicates to be used without extra pushups. This reduces the surprise factor for users, who may well be used to ordinary (function-call-based) casts being known to be strict. Per a gripe from Samuel Williams. This doesn't rise to the level of a bug, IMO, so no back-patch. Discussion: https://postgr.es/m/27571.1550617881@sss.pgh.pa.us
* Fix incorrect strictness test for ArrayCoerceExpr expressions.Tom Lane2019-02-20
| | | | | | | | | | | | | | | | | The recursion in contain_nonstrict_functions_walker() was done wrong, causing the strictness check to be bypassed for a parse node that is the immediate input of an ArrayCoerceExpr node. This could allow, for example, incorrect decisions about whether a strict SQL function can be inlined. I didn't add a regression test, because (a) the bug is so narrow and (b) I couldn't think of a test case that wasn't dependent on a large number of other behaviors, to the point where it would likely soon rot to the point of not testing what it was intended to. I broke this in commit c12d570fa, so back-patch to v11. Discussion: https://postgr.es/m/27571.1550617881@sss.pgh.pa.us
* Make object address handling more robustAlvaro Herrera2019-02-20
| | | | | | | | | pg_identify_object_as_address crashes when passed certain tuples from inconsistent system catalogs. Make it more defensive. Author: Álvaro Herrera Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/20190218202743.GA12392@alvherre.pgsql
* Fix DEFAULT-handling in multi-row VALUES lists for updatable views.Dean Rasheed2019-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INSERT ... VALUES for a single VALUES row is implemented differently from a multi-row VALUES list, which causes inconsistent behaviour in the way that DEFAULT items are handled. In particular, when inserting into an auto-updatable view on top of a table with a column default, a DEFAULT item in a single VALUES row gets correctly replaced with the table column's default, but for a multi-row VALUES list it is replaced with NULL. Fix this by allowing rewriteValuesRTE() to leave DEFAULT items in the VALUES list untouched if the target relation is an auto-updatable view and has no column default, deferring DEFAULT-expansion until the query against the base relation is rewritten. For all other types of target relation, including tables and trigger- and rule-updatable views, we must continue to replace DEFAULT items with NULL in the absence of a column default. This is somewhat complicated by the fact that if an auto-updatable view has DO ALSO rules attached, the VALUES lists for the product queries need to be handled differently from the original query, since the product queries need to act like rule-updatable views whereas the original query has auto-updatable view semantics. Back-patch to all supported versions. Reported by Roger Curley (bug #15623). Patch by Amit Langote and me. Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org
* Mark correctly initial slot snapshots with MVCC type when builtMichael Paquier2019-02-20
| | | | | | | | | | | | | | | | When building an initial slot snapshot, snapshots are marked with historic MVCC snapshots as type with the marker field being set in SnapBuildBuildSnapshot() but not overriden in SnapBuildInitialSnapshot(). Existing callers of SnapBuildBuildSnapshot() do not care about the type of snapshot used, but extensions calling it actually may, as reported. While on it, mark correctly the snapshot type when importing one. This is cosmetic as the field is enforced to 0. Author: Antonin Houska Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/23215.1527665193@localhost Backpatch-through: 9.4
* Use varargs macro for CACHEDEBUGPeter Eisentraut2019-02-19
| | | | Reviewed-by: Andres Freund <andres@anarazel.de>
* Fix omissions in ecpg/test/sql/.gitignore.Tom Lane2019-02-18
| | | | Oversights in commits 050710b36 and e81f0e311.
* Remove line duplicated during conflict resolution.Andres Freund2019-02-18
| | | | | | | | I included the duplicated ExecTypeFromTL in 578b2297 "Remove WITH OIDS support". Reported-By: Peter Eisentraut Discussion: https://postgr.es/m/ba819888-63c6-7f98-6acb-3731142d9414@2ndquadrant.com
* De-clutter display of script runtimes in pg_regress.Tom Lane2019-02-18
| | | | | | Add more whitespace, per suggestion from Peter Eisentraut. Discussion: https://postgr.es/m/e265e2ae-e92e-5ab9-dc68-60b6cb047b3d@2ndquadrant.com
* Provide an extra-float-digits setting for pg_dump / pg_dumpallAndrew Dunstan2019-02-18
| | | | | | | | | | | | | Changes made by commit 02ddd49 mean that dumps made against pre version 12 instances are no longer comparable with those made against version 12 or later instances. This makes cross-version upgrade testing fail in the buildfarm. Experimentation has shown that the error is cured if the dumps are made when extra_float_digits is set to 0. Hence this patch allows for it to be explicitly set rather than relying on pg_dump's builtin default (3 in almost all cases). This feature might have other uses, but should not normally be used. Discussion: https://postgr.es/m/c76f7051-8fd3-ec10-7579-1f8842305b85@2ndQuadrant.com
* Properly end string to make sure ecpglib does not read beyond its boundaries.Michael Meskes2019-02-18
|
* Sync ECPG's CREATE TABLE AS statement with backend's.Michael Meskes2019-02-18
| | | | Author: Higuchi-san ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
* Add bytea datatype to ECPG.Michael Meskes2019-02-18
| | | | | | | | | | | | So far ECPG programs had to treat binary data for bytea column as 'char' type. But this meant converting from/to escaped format with PQunescapeBytea/ PQescapeBytea() and therefore forcing users to add unnecessary code and cost for the conversion in runtime. By adding a dedicated datatype for bytea most of this special handling is no longer needed. Author: Matsumura-san ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) Discussion: https://postgr.es/m/flat/03040DFF97E6E54E88D3BFEE5F5480F737A141F9@G01JPEXMBYT04
* Save PathTargets for distinct/ordered relations in root->upper_targets[].Etsuro Fujita2019-02-18
| | | | | | | | | | For the convenience of extensions, we previously only saved PathTargets for grouped, window, and final relations in root->upper_targets[] in grouping_planner(). To improve the convenience, save PathTargets for distinct and ordered relations as well. Author: Antonin Houska, with an additional change by me Discussion: https://postgr.es/m/10994.1549559088@localhost
* Fix some issues with TAP tests of pg_basebackup and pg_verify_checksumsMichael Paquier2019-02-18
| | | | | | | | | | | | | | ee9e145 has fixed the tests of pg_basebackup for checksums a first time, still one seek() call missed the shot. Also, the data written in files to emulate corruptions was not actually writing zeros as the quoting style was incorrect. Backpatch the portion for pg_basebackup to v11 where these tests have been introduced. The tests of pg_verify_checksums are new as of v12. Author: Michael Banck Discussion: https://postgr.es/m/1550153276.796.35.camel@credativ.de Backpatch-through: 11
* Fix typo in transam.h for OIDs assigned by genbki.plMichael Paquier2019-02-18
| | | | | | | | The actual range of reserved OIDs in this case is [11000,11999] and not [11000,12000]. Author: John Naylor Discussion: https://postgr.es/m/CAJVSVGV5StmK-inxbmrf0nLbBGeaAKnjnqxXmk+4ufeav8JMSA@mail.gmail.com
* Avoid some unnecessary block reads in WAL readerMichael Paquier2019-02-18
| | | | | | | | | | | | | | | | When reading a new page internally and depending on the way the WAL reader facility gets used by plugins, the current implementation of the WAL reader may finish by reading a block multiple times while it is not actually necessary as the requested data length may be equal to what has been already read. This can happen for any size, but is more likely to happen at the end of a page. This can cause performance penalties in plugins which rely on the block reads to be purely sequential, zlib not liking backward reads for example. The new behavior also shaves some cycles when doing recovery. Author: Arthur Zakirov Reviewed-by: Andrey Lepikhov, Michael Paquier, Grigory Smolkin Discussion: https://postgr.es/m/2ddf4a32-517e-d6f4-d992-4a63b6035bfd@postgrespro.ru
* Fix race in dsm_unpin_segment() when handles are reused.Thomas Munro2019-02-18
| | | | | | | | | | | | | | | | | | | Teach dsm_unpin_segment() to skip segments that are in the process of being destroyed by another backend, when searching for a handle. Such a segment cannot possibly be the one we are looking for, even if its handle matches. Another slot might hold a recently created segment that has the same handle value by coincidence, and we need to keep searching for that one. The bug caused rare "cannot unpin a segment that is not pinned" errors on 10 and 11. Similar to commit 6c0fb941 for dsm_attach(). Back-patch to 10, where dsm_unpin_segment() landed. Author: Thomas Munro Reported-by: Justin Pryzby Tested-by: Justin Pryzby (along with other recent DSA/DSM fixes) Discussion: https://postgr.es/m/20190216023854.GF30291@telsasoft.com
* Fix CREATE VIEW to allow zero-column views.Tom Lane2019-02-17
| | | | | | | | | | | | | | | | | | | | | We should logically have allowed this case when we allowed zero-column tables, but it was overlooked. Although this might be thought a feature addition, it's really a bug fix, because it was possible to create a zero-column view via the convert-table-to-view code path, and then you'd have a situation where dump/reload would fail. Hence, back-patch to all supported branches. Arrange the added test cases to provide coverage of the related pg_dump code paths (since these views will be dumped and reloaded during the pg_upgrade regression test). I also made them test the case where pg_dump has to postpone the view rule into post-data, which disturbingly had no regression coverage before. Report and patch by Ashutosh Sharma (test case by me) Discussion: https://postgr.es/m/CAE9k0PkmHdeSaeZt2ujnb_cKucmK3sDDceDzw7+d5UZoNJPYOg@mail.gmail.com
* Mark pg_config() stable rather than immutableJoe Conway2019-02-17
| | | | | | | | | | | | | | | pg_config() has been marked immutable since its inception. As part of a larger discussion around the definition of immutable versus stable and related implications for marking functions parallel safe raised by Andres, the consensus was clearly that pg_config() is stable, since it could possibly change output even for the same minor version with a recompile or installation of a new binary. So mark it stable. Theoretically this could/should be backpatched, but it was deemed to be not worth the effort since in practice this is very unlikely to cause problems in the real world. Discussion: https://postgr.es/m/20181126234521.rh3grz7aavx2ubjv@alap3.anarazel.de
* Remove float8-small-is-zero regression test variant.Andrew Gierth2019-02-16
| | | | | | Since this was also the variant used as an example in the docs, update the docs to use float4-misrounded-input as an example instead, since that is now the only remaining variant file.
* Allow user control of CTE materialization, and change the default behavior.Tom Lane2019-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically we've always materialized the full output of a CTE query, treating WITH as an optimization fence (so that, for example, restrictions from the outer query cannot be pushed into it). This is appropriate when the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE query is non-recursive and side-effect-free, there's no hazard of changing the query results by pushing restrictions down. Another argument for materialization is that it can avoid duplicate computation of an expensive WITH query --- but that only applies if the WITH query is called more than once in the outer query. Even then it could still be a net loss, if each call has restrictions that would allow just a small part of the WITH query to be computed. Hence, let's change the behavior for WITH queries that are non-recursive and side-effect-free. By default, we will inline them into the outer query (removing the optimization fence) if they are called just once. If they are called more than once, we will keep the old behavior by default, but the user can override this and force inlining by specifying NOT MATERIALIZED. Lastly, the user can force the old behavior by specifying MATERIALIZED; this would mainly be useful when the query had deliberately been employing WITH as an optimization fence to prevent a poor choice of plan. Andreas Karlsson, Andrew Gierth, David Fetter Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
* Fix previous MinGW fix.Andrew Gierth2019-02-16
| | | | Definitions required for MinGW need to be outside #if _MSC_VER. Oops.
* Add DECLARE STATEMENT support to ECPG.Michael Meskes2019-02-16
| | | | | | | | | | | | | | | DECLARE STATEMENT is a statement that lets users declare an identifier pointing at a connection. This identifier will be used in other embedded dynamic SQL statement such as PREPARE, EXECUTE, DECLARE CURSOR and so on. When connecting to a non-default connection, the AT clause can be used in a DECLARE STATEMENT once and is no longer needed in every dynamic SQL statement. This makes ECPG applications easier and more efficient. Moreover, writing code without designating connection explicitly improves portability. Authors: Ideriha-san ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>) Kuroda-san ("Kuroda, Hayato" <kuroda.hayato@jp.fujitsu.com>) Discussion: https://postgr.es/m4E72940DA2BF16479384A86D54D0988A565669DF@G01JPEXMBKW04
* Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT.Tom Lane2019-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test for the compiler builtins __builtin_clz, __builtin_ctz, and __builtin_popcount, and make use of these in preference to handwritten C code if they're available. Create src/port infrastructure for "leftmost one", "rightmost one", and "popcount" so as to centralize these decisions. On x86_64, __builtin_popcount generally won't make use of the POPCNT opcode because that's not universally supported yet. Provide code that checks CPUID and then calls POPCNT via asm() if available. This requires indirecting through a function pointer, which is an annoying amount of overhead for a one-instruction operation, but it's probably not worth working harder than this for our current use-cases. I'm not sure we've found all the existing places that could profit from this new infrastructure; but we at least touched all the ones that used copied-and-pasted versions of the bitmapset.c code, and got rid of multiple copies of the associated constant arrays. While at it, replace c-compiler.m4's one-per-builtin-function macros with a single one that can handle all the cases we need to worry about so far. Also, because I'm paranoid, make those checks into AC_LINK checks rather than just AC_COMPILE; the former coding failed to verify that libgcc has support for the builtin, in cases where it's not inline code. David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
* Cygwin and Mingw floating-point fixes.Andrew Gierth2019-02-16
| | | | | | | | | | | | | | Deal with silent-underflow errors in float4 for cygwin and mingw by using our strtof() wrapper; deal with misrounding errors by adding them to the resultmap. Some slight reorganization of declarations was done to avoid duplicating material between cygwin.h and win32_port.h. While here, remove from the resultmap all references to float8-small-is-zero; inspection of cygwin output suggests it's no longer required there, and the freebsd/netbsd/openbsd entries should no longer be necessary (these date back to c. 2000). This commit doesn't remove the file itself nor the documentation references for it; that will happen in a subsequent commit if all goes well.
* Revert attempts to use POPCNT etc instructionsAlvaro Herrera2019-02-15
| | | | | | | | | | | This reverts commits fc6c72747ae6, 109de05cbb03, d0b4663c23b7 and 711bab1e4d19. Somebody will have to try harder before submitting this patch again. I've spent entirely too much time on it already, and the #ifdef maze yet to be written in order for it to build at all got on my nerves. The amount of work needed to get a platform-specific performance improvement that's barely above the noise level is not worth it.
* Refactor index cost estimation functions in view of IndexClause changes.Tom Lane2019-02-15
| | | | | | | | | | | | | | | | | | | Get rid of deconstruct_indexquals() in favor of just iterating over the IndexClause list directly. The extra services that that function used to provide, such as hiding clause commutation and associating the right index column with each clause, are no longer useful given the new data structure. I'd originally thought that it'd provide a useful amount of abstraction by freeing callers from paying attention to the exact clause type of each indexqual, but that hope proves to have been vain, because few callers can ignore the semantic differences between different clause types. Indeed, removing it results in a net code savings, and probably some cycles shaved by not having to build an extra list-of-structs data structure. Also, export a few formerly-static support functions, with the goal of allowing extension AMs to write functionality equivalent to genericcostestimate() without pointless code duplication. Discussion: https://postgr.es/m/24586.1550106354@sss.pgh.pa.us
* Fix compiler builtin usage in new pg_bitutils.cAlvaro Herrera2019-02-15
| | | | | | | | | | | | | | | | | | | | | | Split out these new functions in three parts: one in a new file that uses the compiler builtin and gets compiled with the -mpopcnt compiler option if it exists; another one that uses the compiler builtin but not the compiler option; and finally the fallback with open-coded algorithms. Split out the configure logic: in the original commit, it was selecting to use the -mpopcnt compiler switch together with deciding whether to use the compiler builtin, but those two things are really separate. Split them out. Also, expose whether the builtin exists to Makefile.global, so that src/port's Makefile can decide whether to compile the hw-optimized file. Remove CPUID test for CTZ/CLZ. Make pg_{right,left}most_ones use either the compiler intrinsic or open-coded algo; trying to use the HW-optimized version is a waste of time. Make them static inline functions. Discussion: https://postgr.es/m/20190213221719.GA15976@alvherre.pgsql
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 09:18:22 +0000