aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* 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
* Use standard diff separator for regression.diffsPeter Eisentraut2019-02-15
| | | | | | | | | | | | | Instead of ======..., use the standard separator for a multi-file diff, which is, per POSIX, "diff %s %s %s\n", <diff_options>, <filename1>, <filename2> This makes regression.diffs behave more like a proper diff file, for use with other tools. And it shows the diff options used, for clarity. Discussion: https://www.postgresql.org/message-id/70440c81-37bb-76dd-e48b-b5a9550d5613@2ndquadrant.com
* Fix support for CREATE TABLE IF NOT EXISTS AS EXECUTEMichael Paquier2019-02-15
| | | | | | | | | | | The grammar IF NOT EXISTS for CTAS is supported since 9.5 and documented as such, however the case of using EXECUTE as query has never been covered as EXECUTE CTAS statements and normal CTAS statements are parsed separately. Author: Andreas Karlsson Discussion: https://postgr.es/m/2ddcc188-e37c-a0be-32bf-a56b07c3559e@proxel.se Backpatch-through: 9.5
* Fix race in dsm_attach() when handles are reused.Thomas Munro2019-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | DSM handle values can be reused as soon as the underlying shared memory object has been destroyed. That means that for a brief moment we might have two DSM slots with the same handle. While trying to attach, if we encounter a slot with refcnt == 1, meaning that it is currently being destroyed, we should continue our search in case the same handle exists in another slot. The race manifested as a rare "dsa_area could not attach to segment" error, and was more likely in 10 and 11 due to the lack of distinct seed for random() in parallel workers. It was made very unlikely in in master by commit 197e4af9, and older releases don't usually create new DSM segments in background workers so it was also unlikely there. This fixes the root cause of bug report #15585, in which the error could also sometimes result in a self-deadlock in the error path. It's not yet clear if further changes are needed to avoid that failure mode. Back-patch to 9.4, where dsm.c arrived. Author: Thomas Munro Reported-by: Justin Pryzby, Sergei Kornilov Discussion: https://postgr.es/m/20190207014719.GJ29720@telsasoft.com Discussion: https://postgr.es/m/15585-324ff6a93a18da46@postgresql.org
* Simplify the planner's new representation of indexable clauses a little.Tom Lane2019-02-14
| | | | | | | | | | | | | | | | | | | | | | In commit 1a8d5afb0, I thought it'd be a good idea to define IndexClause.indexquals as NIL in the most common case where the given clause (IndexClause.rinfo) is usable exactly as-is. It'd be more consistent to define the indexquals in that case as being a one-element list containing IndexClause.rinfo, but I thought saving the palloc overhead for making such a list would be worthwhile. In hindsight, that was a great example of "premature optimization is the root of all evil": it's complicated everyplace that needs to deal with the indexquals, requiring duplicative code to handle both the simple case and the not-simple case. I'd initially found that tolerable but it's getting less so as I mop up some areas that I'd not touched in 1a8d5afb0. In any case, two more pallocs during a planner run are surely at the noise level (a conclusion confirmed by a bit of microbenchmarking). So let's change this decision before it becomes set in stone, and insist that IndexClause.indexquals always be a valid list of the actual index quals for the clause. Discussion: https://postgr.es/m/24586.1550106354@sss.pgh.pa.us
* Get rid of another unconstify through API changesPeter Eisentraut2019-02-14
| | | | | | | | This also makes the code in read_client_first_message() more similar to read_client_final_message(). Reported-by: Mark Dilger <hornschnorter@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/53a28052-f9f3-1808-fed9-460fd43035ab%402ndquadrant.com
* Move pattern selectivity code from selfuncs.c to like_support.c.Tom Lane2019-02-14
| | | | | | | | | | | | | | | | | | | | | While at it, refactor patternsel() a bit so that it can be used from the LIKE/regex planner support functions as well. This makes the planner able to deal equally well with either operator or function syntax for these operations. I'm not excited about that as a feature in itself, but it provides a nice model for extensions to follow if they want such behavior for their operations. This change localizes the use of pattern_fixed_prefix() and make_greater_string() so that they no longer need be exported. (We might get pushback from extensions about that, perhaps, in which case I'd be inclined to re-export them in a new header file like_support.h.) This reduces the bulk of selfuncs.c a fair amount, removing ~1370 lines or about one-sixth of that file; it's still too big, but this is progress. Discussion: https://postgr.es/m/24537.1550093915@sss.pgh.pa.us
* Fix portability issues in pg_bitutilsAlvaro Herrera2019-02-13
| | | | | | | | | | | | | | | We were using uint64 function arguments as "long int" arguments to compiler builtins, which fails on machines where long ints are 32 bits: the upper half of the uint64 was being ignored. Fix by using the "ll" builtin variants instead, which on those machines take 64 bit arguments. Also, remove configure tests for __builtin_popcountl() (as well as "long" variants for ctz and clz): the theory here is that any compiler version will provide all widths or none, so one test suffices. Were this theory to be wrong, we'd have to add tests for __builtin_popcountll() and friends, which would be tedious. Per failures in buildfarm member lapwing and ensuing discussion.
* Remove a stray subnormal value from float tests.Andrew Gierth2019-02-13
| | | | | | | | We don't care to assume that input of subnormal float values works, but a stray subnormal value from the upstream Ryu regression test had been left in the test data by mistake. Remove it. Per buildfarm member fulmar.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 13:16:18 +0000