aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Adjust some more comments for WITH OIDS removal.Andres Freund2019-01-21
| | | | | | I missed these in 578b229718e8f. Author: Andres Freund
* Avoid thread-safety problem in ecpglib.Tom Lane2019-01-21
| | | | | | | | | | | | | | | | | | | | | | | | ecpglib attempts to force the LC_NUMERIC locale to "C" while reading server output, to avoid problems with strtod() and related functions. Historically it's just issued setlocale() calls to do that, but that has major problems if we're in a threaded application. setlocale() itself is not required by POSIX to be thread-safe (and indeed is not, on recent OpenBSD). Moreover, its effects are process-wide, so that we could cause unexpected results in other threads, or another thread could change our setting. On platforms having uselocale(), which is required by POSIX:2008, we can avoid these problems by using uselocale() instead. Windows goes its own way as usual, but we can make it safe by using _configthreadlocale(). Platforms having neither continue to use the old code, but that should be pretty much nobody among current systems. This should get back-patched, but let's see what the buildfarm thinks of it first. Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa. Discussion: https://postgr.es/m/31420.1547783697@sss.pgh.pa.us
* Revert "Fix under-quoted filename pattern in pgbench TAP test."Tom Lane2019-01-21
| | | | | | | | This reverts commit 458a1244f1fcf407874482a93b7631ecf5303d6e. It has portability problems on Windows, which will require a little bit of research to fix. Discussion: https://postgr.es/m/20202.1548035461@sss.pgh.pa.us
* Postpone generating tlists and EC members for inheritance dummy children.Etsuro Fujita2019-01-21
| | | | | | | | | | | | | | | | | | | | | Previously, in set_append_rel_size(), we generated tlists and EC members for dummy children for possible use by partition-wise join, even if partition-wise join was disabled or the top parent was not a partitioned table, but adding such EC members causes noticeable planning speed degradation for queries with certain kinds of join quals like "(foo.x + bar.y) = constant" where foo and bar are partitioned tables in cases where there are lots of dummy children, as the EC members lists grow huge, especially for the ECs derived from such join quals, which makes the search for the parent EC members in add_child_rel_equivalences() very time-consuming. Postpone the work until such children are actually involved in a partition-wise join. Reported-by: Sanyo Capobiango Analyzed-by: Justin Pryzby and Alvaro Herrera Author: Amit Langote, with a few additional changes by me Reviewed-by: Ashutosh Bapat Backpatch-through: v11 where partition-wise join was added Discussion: https://postgr.es/m/CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR%2BpqjF%3DrmKBTgpw%40mail.gmail.com
* Allow COPY FROM to filter data using WHERE conditionsTomas Vondra2019-01-20
| | | | | | | | | | | | | Extends the COPY FROM command with a WHERE condition, which allows doing various types of filtering while importing the data (random sampling, condition on a data column, etc.). Until now such filtering required either preprocessing of the input data, or importing all data and then filtering in the database. COPY FROM ... WHERE is an easy-to-use and low-overhead alternative for most simple cases. Author: Surafel Temesgen Reviewed-by: Tomas Vondra, Masahiko Sawada, Lim Myungkyu Discussion: https://www.postgresql.org/message-id/flat/CALAY4q_DdpWDuB5-Zyi-oTtO2uSk8pmy+dupiRe3AvAc++1imA@mail.gmail.com
* Revert "Add valgrind suppressions for wcsrtombs optimizations"Tomas Vondra2019-01-19
| | | | | | | | | | | This reverts commit d3bbc4b96a5b4d055cf636596c6865913a099929. Per discussion, it's not desirable to add valgrind suppressions for outside our own code base (e.g. glibc in this case), especially when the suppressions may be platform-specific. There are better ways to deal with that, e.g. by providing local suppressions. Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com
* Replace @postgresql.org with @lists.postgresql.org for mailinglistsMagnus Hagander2019-01-19
| | | | | | Commit c0d0e54084 replaced the ones in the documentation, but missed out on the ones in the code. Replace those as well, but unlike c0d0e54084, don't backpatch the code changes to avoid breaking translations.
* Fix outdated commentPeter Eisentraut2019-01-19
| | | | | The issue the comment is referring to was fixed by 08859bb5c2cebc132629ca838113d27bb31b990c.
* Fix under-quoted filename pattern in pgbench TAP test.Tom Lane2019-01-18
| | | | | | | | | Avoids issues if build directory's pathname contains regex metacharacters. Raúl Marín Rodríguez Discussion: https://postgr.es/m/CAM6_UM6dGdU39PKAC24T+HD9ouy0jLN9vH6163K8QEEzr__iZw@mail.gmail.com
* Use our own getopt() on OpenBSD.Tom Lane2019-01-18
| | | | | | | | | | | | | | | | Recent OpenBSD (at least 5.9 and up) has a version of getopt(3) that will not cope with the "-:" spec we use to accept double-dash options in postgres.c and postmaster.c. Admittedly, that's a hack because POSIX only requires getopt() to allow alphanumeric option characters. I have no desire to find another way, however, so let's just do what we were already doing on Solaris: force use of our own src/port/getopt.c implementation. In passing, improve some of the comments around said implementation. Per buildfarm and local testing. Back-patch to all supported branches. Discussion: https://postgr.es/m/30197.1547835700@sss.pgh.pa.us
* Fix creation of duplicate foreign keys on partitionsAlvaro Herrera2019-01-18
| | | | | | | | | | | | | | | | | | When creating a foreign key in a partitioned table, if some partitions already have equivalent constraints, we wastefully create duplicates of the constraints instead of attaching to the existing ones. That's inconsistent with the de-duplication that is applied when a table is attached as a partition. To fix, reuse the FK-cloning code instead of having a separate code path. Backpatch to Postgres 11. This is a subtle behavior change, but surely a welcome one since there's no use in having duplicate foreign keys. Discovered by Álvaro Herrera while thinking about a different problem reported by Jesper Pedersen (bug #15587). Author: Álvaro Herrera Discussion: https://postgr.es/m/201901151935.zfadrzvyof4k@alvherre.pgsql
* Move CloneForeignKeyConstraints to tablecmds.cAlvaro Herrera2019-01-18
| | | | | | | | | | | | | | | My commit 3de241dba86f introduced some code to create a clone of a foreign key to a partition, but I put it in pg_constraint.c because it was too close to the contents of the pg_constraint row. With the previous commit that split out the constraint tuple deconstruction into its own routine, it makes more sense to have the FK-cloning function in tablecmds.c, mostly because its static subroutine can then be used by a future bugfix. My initial posting of this patch had this routine as static in tablecmds.c, but sadly this function is already part of the Postgres 11 ABI as exported from pg_constraint.c, so keep it as exported also just to avoid breaking any possible users of it.
* Refactor duplicate code into DeconstructFkConstraintRowAlvaro Herrera2019-01-18
| | | | | | | | | | | My commit 3de241dba86f introduced some code (in tablecmds.c) to obtain data from a pg_constraint row for a foreign key, that already existed in ri_triggers.c. Split it out into its own routine in pg_constraint.c, where it naturally belongs. No functional code changes, only code movement. Backpatch to pg11, because a future bugfix is simpler after this.
* Avoid sometimes printing both tables and their columns in DROP CASCADE.Tom Lane2019-01-18
| | | | | | | | | | | | | | | | | A cascaded drop might find independent reasons to drop both a table and some column of the table (for instance, a schema drop might include dropping a data type used in some table in the schema). Depending on the order of visitation of pg_depend entries, we might report the table column and the whole table as separate objects-to-be-dropped, or we might only report the table. This is confusing and leads to unstable regression test output, so fix it to report only the table regardless of visitation order. Per gripe from Peter Geoghegan. This is just cosmetic from a user's standpoint, and we haven't actually seen regression test problems in practice (yet), so I'll refrain from back-patching. Discussion: https://postgr.es/m/15908.1547762076@sss.pgh.pa.us
* Remove obsolete commentPeter Eisentraut2019-01-18
|
* Fix incorrect relation name in comment of vacuumlazy.cMichael Paquier2019-01-18
| | | | | Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoBiOiapB7YGbWRfNZji3cs1gkEwv=uGLTemaZ9yNKK1DA@mail.gmail.com
* Enforce non-parallel plan when calling current_schema() in newly-added testMichael Paquier2019-01-18
| | | | | | | | | | current_schema() gets called in the recently-added regression test from c5660e0, and can be used in a parallel context, causing its call to fail when creating a temporary schema. Per buildfarm members crake and lapwing. Discussion: https://postgr.es/m/20190118005949.GD1883@paquier.xyz
* Avoid assuming that we know the spelling of getopt_long's error messages.Tom Lane2019-01-17
| | | | | | | | | I've had enough of "fixing" this test case. Whatever value it has is limited to verifying that pgbench fails for an unrecognized switch, and we don't need to assume anything about what getopt_long prints in order to do that. Discussion: https://postgr.es/m/9427.1547701450@sss.pgh.pa.us
* Restrict the use of temporary namespace in two-phase transactionsMichael Paquier2019-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attempting to use a temporary table within a two-phase transaction is forbidden for ages. However, there have been uncovered grounds for a couple of other object types and commands which work on temporary objects with two-phase commit. In short, trying to create, lock or drop an object on a temporary schema should not be authorized within a two-phase transaction, as it would cause its state to create dependencies with other sessions, causing all sorts of side effects with the existing session or other sessions spawned later on trying to use the same temporary schema name. Regression tests are added to cover all the grounds found, the original report mentioned function creation, but monitoring closer there are many other patterns with LOCK, DROP or CREATE EXTENSION which are involved. One of the symptoms resulting in combining both is that the session which used the temporary schema is not able to shut down completely, waiting for being able to drop the temporary schema, something that it cannot complete because of the two-phase transaction involved with temporary objects. In this case the client is able to disconnect but the session remains alive on the backend-side, potentially blocking connection backend slots from being used. Other problems reported could also involve server crashes. This is back-patched down to v10, which is where 9b013dc has introduced MyXactFlags, something that this patch relies on. Reported-by: Alexey Bashtanov Author: Michael Paquier Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/5d910e2e-0db8-ec06-dd5f-baec420513c3@imap.cc Backpatch-through: 10
* Postpone aggregate checks until after collation is assigned.Andrew Gierth2019-01-17
| | | | | | | | | | | | | | | | | | | | | | | Previously, parseCheckAggregates was run before assign_query_collations, but this causes problems if any expression has already had a collation assigned by some transform function (e.g. transformCaseExpr) before parseCheckAggregates runs. The differing collations would cause expressions not to be recognized as equal to the ones in the GROUP BY clause, leading to spurious errors about unaggregated column references. The result was that CASE expr WHEN val ... would fail when "expr" contained a GROUPING() expression or matched one of the group by expressions, and where collatable types were involved; whereas the supposedly identical CASE WHEN expr = val ... would succeed. Backpatch all the way; this appears to have been wrong ever since collations were introduced. Per report from Guillaume Lelarge, analysis and patch by me. Discussion: https://postgr.es/m/CAECtzeVSO_US8C2Khgfv54ZMUOBR4sWq+6_bLrETnWExHT=rFg@mail.gmail.com Discussion: https://postgr.es/m/87muo0k0c7.fsf@news-spur.riddles.org.uk
* Reorganize planner code moved in b60c39759908Alvaro Herrera2019-01-16
| | | | | | | | It seems modules are better defined like this instead of the original split. Per complaints from David Rowley as well as Amit Langote's self review. Discussion: https://postgr.es/m/CAKJS1f988rsyhwvLgfT-y1UCYUfXDOv67ENQk=v24OxhsZOzZw@mail.gmail.com
* Increase test coverage in RI_Initial_Check()Peter Eisentraut2019-01-16
| | | | | | | | This covers the special error handling of FKCONSTR_MATCH_FULL. Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> Reviewed-by: Mi Tar <mmitar@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/
* Increase test coverage in RI_FKey_fk_upd_check_required()Peter Eisentraut2019-01-16
| | | | | | | | | This checks the code path of FKCONSTR_MATCH_FULL and RI_KEYS_SOME_NULL. Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> Reviewed-by: Mi Tar <mmitar@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/
* Increase test coverage in RI_FKey_pk_upd_check_required()Peter Eisentraut2019-01-16
| | | | | | | | | This checks the case where the primary key has at least one null column. Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> Reviewed-by: Mi Tar <mmitar@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/
* Add test case for ON DELETE NO ACTION/RESTRICTPeter Eisentraut2019-01-16
| | | | | | | | | This was previously not covered at all; function RI_FKey_restrict_del() was not exercised in the tests. Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> Reviewed-by: Mi Tar <mmitar@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/
* Don't duplicate parallel seqscan shmem sizing logic in nbtree.Andres Freund2019-01-15
| | | | | | | | | | | This is architecturally mildly problematic, which becomes more pronounced with the upcoming introduction of pluggable storage. To fix, teach heap_parallelscan_estimate() to deal with SnapshotAny snapshots, and then use it from _bt_parallel_estimate_shared(). Author: Andres Freund Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
* Move vacuumlazy.c into access/heap.Andres Freund2019-01-15
| | | | | | | | It's heap table storage specific code that can't realistically be generalized into table AM agnostic code. Author: Andres Freund Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
* Fix parent of WCO qual.Andres Freund2019-01-15
| | | | | | | | | | | | | | The parent of some WCO expressions was, apparently by accident, set to the the source of DML queries, rather than the target table. This causes problems for the upcoming pluggable storage work, because the target and source table might be of different storage types. It's possible that this is already problematic, but neither experimenting nor inquiries on -hackers have found them. So don't backpatch for now. Author: Andres Freund Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de
* Finish reverting "recheck_on_update" patch.Tom Lane2019-01-15
| | | | | | | | | | | | This reverts commit c203d6cf8 and some follow-on fixes, completing the task begun in commit 5d28c9bd7. If that feature is ever resurrected, the code will look quite a bit different from this, so it seems best to start from a clean slate. The v11 branch is not touched; in that branch, the recheck_on_update storage option remains present, but nonfunctional and undocumented. Discussion: https://postgr.es/m/20190114223409.3tcvejfhlvbucrv5@alap3.anarazel.de
* Don't include genam.h from execnodes.h and relscan.h anymore.Andres Freund2019-01-14
| | | | | | | | | | | | | | | | | | | This is the genam.h equivalent of 4c850ecec649c (which removed heapam.h from a lot of other headers). There's still a few header includes of genam.h, but not from central headers anymore. As a few headers are not indirectly included anymore, execnodes.h and relscan.h need a few additional includes. Some of the depended on types were replacable by using the underlying structs, but e.g. for Snapshot in execnodes.h that'd have gotten more invasive than reasonable in this commit. Like the aforementioned commit 4c850ecec649c, this requires adding new genam.h includes to a number of backend files, which likely is also required in a few external projects. Author: Andres Freund Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
* Make naming of tupdesc related structs more consistent with the rest of PG.Andres Freund2019-01-14
| | | | | | | | | | | | | | We usually don't change the name of structs between the struct name itself and the name of the typedef. Additionally, structs that are usually used via a typedef that hides being a pointer, are commonly suffixed Data. Change tupdesc code to follow those convention. This is triggered by a future patch that intends to forward declare TupleDescData in another header - keeping with the naming scheme makes that easier to understand. Author: Andres Freund Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
* Remove too generically named MissingPtr typedef.Andres Freund2019-01-14
| | | | | | | | | | As there's only a single user of the typedef in the entire codebase, just use the underlying struct directly. Per complaint from Alvaro Herrera Author: Andres Freund Discussion: https://postgr.es/m/201901141836.oxtm4uzc63j3@alvherre.pgsql
* Don't include heapam.h from others headers.Andres Freund2019-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | heapam.h previously was included in a number of widely used headers (e.g. execnodes.h, indirectly in executor.h, ...). That's problematic on its own, as heapam.h contains a lot of low-level details that don't need to be exposed that widely, but becomes more problematic with the upcoming introduction of pluggable table storage - it seems inappropriate for heapam.h to be included that widely afterwards. heapam.h was largely only included in other headers to get the HeapScanDesc typedef (which was defined in heapam.h, even though HeapScanDescData is defined in relscan.h). The better solution here seems to be to just use the underlying struct (forward declared where necessary). Similar for BulkInsertState. Another problem was that LockTupleMode was used in executor.h - parts of the file tried to cope without heapam.h, but due to the fact that it indirectly included it, several subsequent violations of that goal were not not noticed. We could just reuse the approach of declaring parameters as int, but it seems nicer to move LockTupleMode to lockoptions.h - that's not a perfect location, but also doesn't seem bad. As a number of files relied on implicitly included heapam.h, a significant number of files grew an explicit include. It's quite probably that a few external projects will need to do the same. Author: Andres Freund Reviewed-By: Alvaro Herrera Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
* Fix typos in documentation and for one wait eventMichael Paquier2019-01-15
| | | | | | | | | These have been found while cross-checking for the use of unique words in the documentation, and a wait event was not getting generated in a way consistent to what the documentation provided. Author: Alexander Lakhin Discussion: https://postgr.es/m/9b5a3a85-899a-ae62-dbab-1e7943aa5ab1@gmail.com
* Re-add default_with_oids GUC to avoid breaking old dump files.Andres Freund2019-01-14
| | | | | | | | | | | | | | After 578b229718 / the removal of WITH OIDS support, older dump files containing SET default_with_oids = false; either report unnecessary errors (as the subsequent tables have no oids) or even fail to restore entirely (when using transaction mode). To avoid that, re-add the GUC, but don't allow setting it to true. Per complaint from Tom Lane. Author: Amit Khandekar, editorialized by me Discussion: https://postgr.es/m/CAJ3gD9dZyxrtL0rJfoNoOj6v7fJSDaXBngi9wy5XU8m-ioXhAA@mail.gmail.com
* Fix unique INCLUDE indexes on partitioned tablesAlvaro Herrera2019-01-14
| | | | | | | | | | We were considering the INCLUDE columns as part of the key, allowing unicity-violating rows to be inserted in different partitions. Concurrent development conflict in eb7ed3f30634 and 8224de4f42cc. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190109065109.GA4285@telsasoft.com
* Detach postmaster process from pg_ctl's session at server startup.Heikki Linnakangas2019-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pg_ctl is supposed to daemonize the postmaster process, so that it's not affected by signals to the launching process group. Before this patch, if you had a shell script that used "pg_ctl start", and you interrupted the shell script after postmaster had been launched, postmaster was also killed. To fix, call setsid() after forking the postmaster process. Long time ago, we had a 'silent_mode' option, which daemonized the postmaster process by calling setsid(), but that was removed back in 2011 (commit f7ea6beaf4). We discussed bringing that back in some form, but pg_ctl is the documented way of launching postmaster to the background, so putting the setsid() call in pg_ctl itself seems appropriate. Just putting postmaster in a separate session would change the behavior when you interrupt "pg_ctl -w start", e.g. with CTRL-C, while it's waiting for postmaster to start. The historical behavior has been that interrupting pg_ctl aborts the server launch, which is handy if the server is stuck in recovery, for example, and won't fully start up. To keep that behavior, install a signal handler in pg_ctl, to explicitly kill postmaster, if pg_ctl is interrupted while it's waiting for the server to start up. This isn't 100% watertight, there is a small window after forking the postmaster process, where the signal handler doesn't know the postmaster's PID yet, but seems good enough. Arguably this is a long-standing bug, but I refrained from back-batching, out of fear of breaking someone's scripts that depended on the old behavior. Reviewed by Tom Lane. Report and original patch by Paul Guo, with feedback from Michael Paquier. Discussion: https://www.postgresql.org/message-id/CAEET0ZH5Bf7dhZB3mYy8zZQttJrdZg_0Wwaj0o1PuuBny1JkEw%40mail.gmail.com
* fix typoAndrew Dunstan2019-01-13
|
* Make DLSUFFIX easily discoverable by build scriptsAndrew Dunstan2019-01-13
| | | | | | | | | This will enable things like the buildfarm client to discover more reliably if certain libraries have been installed. Discussion: https://postgr.es/m/859e7c91-7ef4-d4b4-2ca2-8046e0cbee09@2ndQuadrant.com Backpatch to all live branches.
* Make Emacs perl-mode indent more like perltidy.Noah Misch2019-01-13
| | | | | | | | | | This especially helps braces that surround code blocks. Back-patch to v11, where commit 56fb890ace8ac0ca955ae0803c580c2074f876f6 first appeared; before that, settings were even more distant from perltidy. Reviewed by Andrew Dunstan. Discussion: https://postgr.es/m/20190103055355.GB267595@gust.leadboat.com
* Improve missing-program error handling in make_ctags and make_etags.Tom Lane2019-01-13
| | | | | | | | | | If ctags (resp. etags) isn't installed, these scripts naturally fail, but the error messages were less clear than one could wish. It seems worth installing an explicit test to improve that. Nikolay Shaplov, with suggestions from Michael Paquier and Andrew Dunstan Discussion: https://postgr.es/m/2394207.ccz7JgCJsh@x200m
* Fix error message for logical replication targetsMichael Paquier2019-01-13
| | | | | | This fixes an oversight from 373bda6. Noted by Erik Rijkers.
* Change default of recovery_target_timeline to 'latest'Peter Eisentraut2019-01-13
| | | | | | | | | This is what one usually wants for recovery and almost always wants for a standby. Discussion: https://www.postgresql.org/message-id/flat/6dd2c23a-4162-8469-410f-bfe146e28c0c@2ndquadrant.com/ Reviewed-by: David Steele <david@pgmasters.net> Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Improve error messages for incorrect types of logical replication targetsMichael Paquier2019-01-13
| | | | | | | | | | | If trying to use something else than a plain table as logical replication target, a rather-generic error message gets used to report the problem. This can be confusing when it comes to foreign tables and partitioned tables, so use more dedicated messages in these cases. Author: Amit Langote Reviewed-by: Peter Eisentraut, Magnus Hagander, Michael Paquier Discussion: https://postgr.es/m/41799bee-40eb-7bb5-80b1-325ce17518bc@lab.ntt.co.jp
* Remove heapam.h include made superfluous by b60c3975990.Andres Freund2019-01-12
| | | | | | Noticed this while working on another patch. Author: Andres Freund
* Free pre-modification HeapTuple in ALTER TABLE ... TYPE ...Andrew Dunstan2019-01-11
| | | | | | | | This was an oversight in commit 3b174b1a3. Per offline gripe from Alvaro Herrera Backpatch to release 11.
* Avoid sharing PARAM_EXEC slots between different levels of NestLoop.Tom Lane2019-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to now, createplan.c attempted to share PARAM_EXEC slots for NestLoopParams across different plan levels, if the same underlying Var was being fed down to different righthand-side subplan trees by different NestLoops. This was, I think, more of an artifact of using subselect.c's PlannerParamItem infrastructure than an explicit design goal, but anyway that was the end result. This works well enough as long as the plan tree is executing synchronously, but the feature whereby Gather can execute the parallelized subplan locally breaks it. An upper NestLoop node might execute for a row retrieved from a parallel worker, and assign a value for a PARAM_EXEC slot from that row, while the leader's copy of the parallelized subplan is suspended with a different active value of the row the Var comes from. When control eventually returns to the leader's subplan, it gets the wrong answers if the same PARAM_EXEC slot is being used within the subplan, as reported in bug #15577 from Bartosz Polnik. This is pretty reminiscent of the problem fixed in commit 46c508fbc, and the proper fix seems to be the same: don't try to share PARAM_EXEC slots across different levels of controlling NestLoop nodes. This requires decoupling NestLoopParam handling from PlannerParamItem handling, although the logic remains somewhat similar. To avoid bizarre division of labor between subselect.c and createplan.c, I decided to move all the param-slot-assignment logic for both cases out of those files and put it into a new file paramassign.c. Hopefully it's a bit better documented now, too. A regression test case for this might be nice, but we don't know a test case that triggers the problem with a suitably small amount of data. Back-patch to 9.6 where we added Gather nodes. It's conceivable that related problems exist in older branches; but without some evidence for that, I'll leave the older branches alone. Discussion: https://postgr.es/m/15577-ca61ab18904af852@postgresql.org
* Add value 'current' for recovery_target_timelinePeter Eisentraut2019-01-11
| | | | | | | | | | | | | This value represents the default behavior of using the current timeline. Previously, this was represented by an empty string. (Before the removal of recovery.conf, this setting could not be chosen explicitly but was used when recovery_target_timeline was not mentioned at all.) Discussion: https://www.postgresql.org/message-id/flat/6dd2c23a-4162-8469-410f-bfe146e28c0c@2ndquadrant.com/ Reviewed-by: David Steele <david@pgmasters.net> Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Fix missing values when doing ALTER TABLE ALTER COLUMN TYPEAndrew Dunstan2019-01-10
| | | | | | | | | | | | | | This was an oversight in commit 16828d5c. If the table is going to be rewritten, we simply clear all the missing values from all the table's attributes, since there will no longer be any rows with the attributes missing. Otherwise, we repackage the missing value in an array constructed with the new type specifications. Backpatch to release 11. This fixes bug #15446, reported by Dmitry Molotkov Reviewed by Dean Rasheed
* Add .gitignore entry for a derived file created by "make distprep".Tom Lane2019-01-10
| | | | | | | I chanced to notice that "make distprep" leaves a state of the tree that git complains about. It's been like this for awhile, but given the lack of complaints it probably doesn't need back-patching.
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-30 23:03:50 +0000