aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Reindent Perl files with perltidy version 20170521.Tom Lane2018-04-25
| | | | Discussion: https://postgr.es/m/CABUevEzK3cNiHZQ18f5tK0guoT+cN_jWeVzhYYxY=r+1Q3SmoA@mail.gmail.com
* Change pgindent/README to specify that we use perltidy version 20170521.Tom Lane2018-04-25
| | | | | | | Per discussion, this is now the project's standard version. Update the obsolete URL, and explain how to install a specific version. Discussion: https://postgr.es/m/CABUevEzK3cNiHZQ18f5tK0guoT+cN_jWeVzhYYxY=r+1Q3SmoA@mail.gmail.com
* Update ExecInitPartitionInfo commentAlvaro Herrera2018-04-24
| | | | | | | | | Remove the words "if not already done." This obsolete wording corresponds to an early development version of what became edd44738bc8. Author: Etsuro Fujita Reviewed-by: Amit Langote Discussion: https://postgr.es/m/5ADF117B.5030606@lab.ntt.co.jp
* Initialize ExprStates once in run-time partition pruningAlvaro Herrera2018-04-24
| | | | | | | | | | | Instead of doing ExecInitExpr every time a Param needs to be evaluated in run-time partition pruning, do it once during run-time pruning set-up and cache the exprstate in PartitionPruneContext, saving a lot of work. Author: David Rowley Reviewed-by: Amit Langote, Álvaro Herrera Discussion: https://postgr.es/m/CAKJS1f8-x+q-90QAPDu_okhQBV4DPEtPz8CJ=m0940GyT4DA4w@mail.gmail.com
* Add GUC enable_partition_pruningAlvaro Herrera2018-04-23
| | | | | | | | | | | | | | | | | | | | | | This controls both plan-time and execution-time new-style partition pruning. While finer-grain control is possible (maybe using an enum GUC instead of boolean), there doesn't seem to be much need for that. This new parameter controls partition pruning for all queries: trivially, SELECT queries that affect partitioned tables are naturally under its control since they are using the new technology. However, while UPDATE/DELETE queries do not use the new code, we make the new GUC control their behavior also (stealing control from constraint_exclusion), because it is more natural, and it leads to a more natural transition to the future in which those queries will also use the new pruning code. Constraint exclusion still controls pruning for regular inheritance situations (those not involving partitioned tables). Author: David Rowley Review: Amit Langote, Ashutosh Bapat, Justin Pryzby, David G. Johnston Discussion: https://postgr.es/m/CAKJS1f_0HwsxJG9m+nzU+CizxSdGtfe6iF_ykPYBiYft302DCw@mail.gmail.com
* Fix handling of partition bounds for boolean partitioning columns.Tom Lane2018-04-23
| | | | | | | | | | | | | | | | | Previously, you could partition by a boolean column as long as you spelled the bound values as string literals, for instance FOR VALUES IN ('t'). The trouble with this is that ruleutils.c printed that as FOR VALUES IN (TRUE), which is reasonable syntax but wasn't accepted by the grammar. That results in dump-and-reload failures for such cases. Apply a minimal fix that just causes TRUE and FALSE to be converted to strings 'true' and 'false'. This is pretty grotty, but it's too late for a more principled fix in v11 (to say nothing of v10). We should revisit the whole issue of how partition bound values are parsed for v12. Amit Langote Discussion: https://postgr.es/m/e05c5162-1103-7e37-d1ab-6de3e0afaf70@lab.ntt.co.jp
* Fix typo in logical truncate replicationPeter Eisentraut2018-04-23
| | | | This could result in some misbehavior in a cascading replication setup.
* Make Emacs settings match perltidy configurationPeter Eisentraut2018-04-23
| | | | | | Set Emacs's perl-continued-statement-offset to match perltidy's --continuation-indentation, which is 2 (not overridden in PostgreSQL's profile) rather than the 4 that Emacs uses by default.
* Add missing pstrdupAlvaro Herrera2018-04-23
| | | | | | | Lifetime of the input string is not right, so create a separate copy. Author: Amit Langote Discussion: https://postgr.es/m/a2773420-50d1-0a42-3396-fe42b0921134@lab.ntt.co.jp
* Remove useless default clause in switchAlvaro Herrera2018-04-23
| | | | | The switch covers all values of the enum driver variable, so having a default: clause is useless, even if it's only to do Assert(false).
* Make bms_prev_member work correctly with a 64 bit bitmapwordTeodor Sigaev2018-04-23
| | | | | | | | | | | | 5c067521 erroneously had coded bms_prev_member assuming that a bitmapword would always hold 32 bits and started it's search on what it thought was the highest 8-bits of the word. This was not the case if bitmapwords were 64 bits. In passing add a test to exercise this function a little. Previously there was no coverage at all. David Rowly
* Fix wrong validation of top-parent pointer during page deletion in Btree.Teodor Sigaev2018-04-23
| | | | | | | | | | | | | | | | | | | | | After introducing usage of t_tid of inner or page high key for storing number of attributes of tuple, validation of tuple's ItemPointer with ItemPointerIsValid becomes incorrect, it's need to validate only blocknumber of ItemPointer. Missing this causes a incorrect page deletion, fix that. Test is added. BTW, current contrib/amcheck doesn't fail on index corrupted by this way. Also introduce BTreeTupleGetTopParent/BTreeTupleSetTopParent macroses to improve code readability and to avoid possible confusion with page high key: high key is used to store top-parent link for branch to remove. Bug found by Michael Paquier, but bug doesn't exist in previous versions because t_tid was set to P_HIKEY. Author: Teodor Sigaev Reviewer: Peter Geoghegan Discussion: https://www.postgresql.org/message-id/flat/20180419052436.GA16000%40paquier.xyz
* Make PGJIT_* macros safer.Heikki Linnakangas2018-04-23
| | | | | Author: David Rowley Discussion: https://www.postgresql.org/message-id/CAKJS1f8Ge2y0sDs6RQEJFH-vjb-bWhs86rCX4Fp4FZ+TmxtRkw@mail.gmail.com
* Add comment explaining BGWORKER_BYPASS_ALLOWCONNMagnus Hagander2018-04-23
| | | | Suggested by Michael Paquier
* Add missing "static" marker.Tom Lane2018-04-21
| | | | Per pademelon.
* Test conversion of NaN between float4 and float8.Tom Lane2018-04-20
| | | | | | | | | | | | | Results from buildfarm member opossum suggest that this doesn't work quite right on that platform. We've seen issues with NaN support on MIPS/NetBSD before ... allegedly they fixed this stuff back in 2010, but maybe only for small values of "fixed". If, in fact, opossum fails this test then I plan to revert it; it's mainly for diagnostic purposes rather than something we'd necessarily keep long-term. I think that the failures in window.sql could be worked around with some code duplication, but I want to verify my theory about the cause first.
* Fix a couple minor typosStephen Frost2018-04-20
| | | | | | | | | In commit f0e4475, GetIndexOpClass was renamed to ResolveOpClass, but the comment in typecmds.c didn't get the memo. In objectaddress.c, missing 'of' in a comment. Both noticed by Vik Fearing, patch is mine though.
* Don't run fast_default regression test in parallel with other tests.Tom Lane2018-04-20
| | | | | | | | | | | | | Since it sets up an event trigger that would fire on DDL done by any concurrent test script, the original scheduling is just an invitation to irreproducible test failures. (The fact that we found a bug through exactly such irreproducible test failures doesn't really change the calculus here: this script is a hazard to anything that runs in parallel with it today or might be added to that parallel group in future. No, I don't believe that the trigger is protecting itself sufficiently to avoid all possible trouble.) Discussion: https://postgr.es/m/5767.1523995174@sss.pgh.pa.us
* Fix race conditions when an event trigger is added concurrently with DDL.Tom Lane2018-04-20
| | | | | | | | | | | | | | | | | | | | | | | EventTriggerTableRewrite crashed if there were table_rewrite triggers present, but there had not been when the calling command started. EventTriggerDDLCommandEnd called ddl_command_end triggers if present, even if there had been no such triggers when the calling command started, which would lead to a failure in pg_event_trigger_ddl_commands. In both cases, fix by doing nothing; it's better to wait till the next command when things will be properly initialized. In passing, remove an elog(DEBUG1) call that might have seemed interesting four years ago but surely isn't today. We found this because of intermittent failures in the buildfarm. Thanks to Alvaro Herrera and Andrew Gierth for analysis. Back-patch to 9.5; some of this code exists before that, but the specific hazards we need to guard against don't. Discussion: https://postgr.es/m/5767.1523995174@sss.pgh.pa.us
* Tweak a couple of planner APIs to save recalculating join relids.Tom Lane2018-04-20
| | | | Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se
* Change more places to be less trusting of RestrictInfo.is_pushed_down.Tom Lane2018-04-20
| | | | | | | | | | | | | | | | | | | | | On further reflection, commit e5d83995e didn't go far enough: pretty much everywhere in the planner that examines a clause's is_pushed_down flag ought to be changed to use the more complicated behavior where we also check the clause's required_relids. Otherwise we could make incorrect decisions about whether, say, a clause is safe to use as a hash clause. Some (many?) of these places are safe as-is, either because they are never reached while considering a parameterized path, or because there are additional checks that would reject a pushed-down clause anyway. However, it seems smarter to just code them all the same way rather than rely on easily-broken reasoning of that sort. In support of that, invent a new macro RINFO_IS_PUSHED_DOWN that should be used in place of direct tests on the is_pushed_down flag. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se
* Improve consistency of comments in system catalog headers.Tom Lane2018-04-19
| | | | | | | | | | | | | Use the term "system catalog" rather than "system relation" in assorted places where it's clearly referring to a table rather than, say, an index. Use more natural word order in the header boilerplate, improve some of the one-liner catalog descriptions, and fix assorted random deviations from the normal boilerplate. All purely neatnik-ism, but why not. John Naylor, some additional cleanup by me Discussion: https://postgr.es/m/CAJVSVGUeJmFB3h-NJ18P32NPa+kzC165nm7GSoGHfPaN80Wxcw@mail.gmail.com
* Fix incorrect handling of join clauses pushed into parameterized paths.Tom Lane2018-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause ends up attached to a lower outer join, we'd misclassify it as being a "join filter" not a plain "filter" condition at that node, leading to wrong query results. To fix, teach extract_actual_join_clauses to examine each join clause's required_relids, not just its is_pushed_down flag. (The latter now seems vestigial, or at least in need of rethinking, but we won't do anything so invasive as redefining it in a bug-fix patch.) This has been wrong since we introduced parameterized paths in 9.2, though it's evidently hard to hit given the lack of previous reports. The test case used here involves a lateral function call, and I think that a lateral reference may be required to get the planner to select a broken plan; though I wouldn't swear to that. In any case, even if LATERAL is needed to trigger the bug, it still affects all supported branches, so back-patch to all. Per report from Andreas Karlsson. Thanks to Andrew Gierth for preliminary investigation. Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se
* Remove quick path in ExecInitPartitionInfo for equal tupdescsAlvaro Herrera2018-04-19
| | | | | | | | | | | | I added this "optimization" on top of Amit Langote's 158b7bc6d779, but the quick path is never taken because the partition uses a different pg_type oid than its parent table (causing equalTupleDescs to return false). Changing that requires more analysis and is too considered dangerous at this point in the cycle, so revert it. We might make it work someday, but not for pg11. Discussion: https://postgr.es/m/825031be-942c-8c24-6163-13c27f217a3d@lab.ntt.co.jp
* Plural of modulus is moduliAlvaro Herrera2018-04-19
|
* Rework code to determine partition pruning procedureAlvaro Herrera2018-04-19
| | | | | | | | | | | | | | | | | | Amit Langote reported that partition prune was unable to work with arrays, enums, etc, which led him to research the appropriate way to match query clauses to partition keys: instead of searching for an exact match of the expression's type, it is better to rely on the fact that the expression qual has already been resolved to a specific operator, and that the partition key is linked to a specific operator family. With that info, it's possible to figure out the strategy and comparison function to use for the pruning clause in a manner that works reliably for pseudo-types also. Include new test cases that demonstrate pruning where pseudotypes are involved. Author: Amit Langote, Álvaro Herrera Discussion: https://postgr.es/m/2b02f1e9-9812-9c41-972d-517bdc0f815d@lab.ntt.co.jp
* Enlarge find_other_exec's meager fgets bufferAlvaro Herrera2018-04-19
| | | | | | | | | The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/CAMGcDxfLfpYU_Jru++L6ARPCOyxr0W+2O3Q54TDi5XdYeU36ow@mail.gmail.com
* Fix datatype for number of heap tuples during last cleanupTeodor Sigaev2018-04-19
| | | | | | | | | | | | | | | | | It appears that new fields introduced in 857f9c36 have inconsistent datatypes: BTMetaPageData.btm_last_cleanup_num_heap_tuples is of float4 type, while xl_btree_metadata.last_cleanup_num_heap_tuples is of double type. IndexVacuumInfo.num_heap_tuples, which is a source of values for both former fields is of double type. So, make both those fields in BTMetaPageData and xl_btree_metadata use float8 type in order to match the precision of the source. That shouldn't be double type, because we always use types with explicit width in WAL. Patch introduces incompatibility of on-disk format since 857f9c36 commit, but that versions never was released, so just bump catalog version to avoid possible confusion. Author: Alexander Korortkov
* Adjust _bt_insertonpg() commentsTeodor Sigaev2018-04-19
| | | | | | | | Remove an obsolete reference to the 'afteritem' argument, which was removed by commit bc292937. Add a comment that clarifies how _bt_insertonpg() indirectly handles the insertion of high key items. Author: Peter Geoghegan
* Handle XLOG_BTREE_META_CLEANUP in btree_desc() and btree_identify()Teodor Sigaev2018-04-19
| | | | | | | | New WAL record XLOG_BTREE_META_CLEANUP introduced in 857f9c36 has no handling in btree_desc() and btree_identify(). This patch implements corresponding handling. Alexander Korotkov
* Adjust INCLUDE index truncation comments and code.Teodor Sigaev2018-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add several assertions that ensure that we're dealing with a pivot tuple without non-key attributes where that's expected. Also, remove the assertion within _bt_isequal(), restoring the v10 function signature. A similar check will be performed for the page highkey within _bt_moveright() in most cases. Also avoid dropping all objects within regression tests, to increase pg_dump test coverage for INCLUDE indexes. Rather than using infrastructure that's generally intended to be used with reference counted heap tuple descriptors during truncation, use the same function that was introduced to store flat TupleDescs in shared memory (we use a temp palloc'd buffer). This isn't strictly necessary, but seems more future-proof than the old approach. It also lets us avoid including rel.h within indextuple.c, which was arguably a modularity violation. Also, we now call index_deform_tuple() with the truncated TupleDesc, not the source TupleDesc, since that's more robust, and saves a few cycles. In passing, fix a memory leak by pfree'ing truncated pivot tuple memory during CREATE INDEX. Also pfree during a page split, just to be consistent. Refactor _bt_check_natts() to be more readable. Author: Peter Geoghegan with some editorization by me Reviewed by: Alexander Korotkov, Teodor Sigaev Discussion: https://www.postgresql.org/message-id/CAH2-Wz%3DkCWuXeMrBCopC-tFs3FbiVxQNjjgNKdG2sHxZ5k2y3w%40mail.gmail.com
* Improve error detection/reporting in Catalog.pm and genbki.pl.Tom Lane2018-04-18
| | | | | | | | | | | | | | Clean up error messages relating to mistakes in .dat files: make sure they provide the .dat file name and line number, not the place in the Perl script that's reporting the problem. Adopt more uniform message phrasing, too. Make genbki.pl spit up on unrecognized field names in the input hashes. Previously, it just silently ignored such fields, which could make a misspelled field name into a very hard-to-decipher problem. (This is in genbki.pl, *not* Catalog.pm, because we don't want reformat_dat_file.pl to complain about unrecognized fields. We'd rather it silently dropped them, to facilitate removing unwanted fields after a reorganization.)
* Better fix for deadlock hazard in CREATE INDEX CONCURRENTLY.Tom Lane2018-04-18
| | | | | | | | | | | | | | Commit 54eff5311 did not account for the possibility that we'd have a transaction snapshot due to default_transaction_isolation being set high enough to require one. The transaction snapshot is enough to hold back our advertised xmin and thus risk deadlock anyway. The only way to get rid of that snap is to start a new transaction, so let's do that instead. Also throw in an assert checking that we really have gotten to a state where no xmin is being advertised. Back-patch to 9.4, like the previous commit. Discussion: https://postgr.es/m/CAMkU=1ztk3TpQdcUNbxq93pc80FrXUjpDWLGMeVBDx71GHNwZQ@mail.gmail.com
* Rationalize handling of single and double quotes in bootstrap data.Tom Lane2018-04-17
| | | | | | | | | | | | | | | | | | | | | | | | Change things around so that proper quoting of values interpolated into the BKI data by initdb is the responsibility of initdb, not something we half-heartedly handle by putting double quotes into the raw BKI data. (Note: experimentation shows that it still doesn't work to put a double quote into the initial superuser username, but that's the fault of inadequate quoting while interpolating the name into SQL scripts; the BKI aspect of it works fine now.) Having done that, we can remove the special-case handling of values that look like "something" from genbki.pl, and instead teach it to escape double --- and single --- quotes properly. This removes the nowhere-documented need to treat those specially in the BKI source data; whatever you write will be passed through unchanged into the inserted data value, modulo Perl's rules about single-quoted strings. Add documentation explaining the (pre-existing) handling of backslashes in the BKI data. Per an earlier discussion with John Naylor. Discussion: https://postgr.es/m/CAJVSVGUNao=-Q2-vAN3PYcdF5tnL5JAHwGwzZGuYHtq+Mk_9ng@mail.gmail.com
* Rationalize handling of array type names in bootstrap data.Tom Lane2018-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, Catalog.pm turned a C array type declaration in the catalog header files into a SQL type, e.g., 'foo[]'. Along the way, genbki.pl turned this into '_foo' for the purpose of type lookups, but wrote 'foo[]' to postgres.bki. During bootstrap, bootscanner.l had to have a special case rule to tokenize this, and then MapArrayTypeName() would turn 'foo[]' into '_foo' one more time. This seems unnecessarily complicated, especially since nobody cares that much about the readability of postgres.bki. Instead, make Catalog.pm convert the C declaration into '_foo' to start with, and preserve that representation of the type name throughout bootstrap data processing. Then rip out the special-case code in bootscanner.l and bootstrap.c. This changes postgres.bki to the extent that array fields are now declared like proconfig = _text , rather than proconfig = text[] , No documentation update, since the SGML docs didn't mention any of this in the first place, and it's all pretty transparent to writers of catalog header files anyway. John Naylor Discussion: https://postgr.es/m/CAJVSVGUNao=-Q2-vAN3PYcdF5tnL5JAHwGwzZGuYHtq+Mk_9ng@mail.gmail.com
* Simplify genbki.pl's data quoting rules.Tom Lane2018-04-17
| | | | | | | | | | | | | | | | | | | | During the bootstrap data format conversion, it seemed important for verifiability's sake that the generated postgres.bki file stayed the same as before. That resulted in adding a bunch of ad-hoc rules about when to quote emitted data values, to match previous manual decisions that had often quoted values unnecessarily. Now that the conversion is complete, it seems fine to remove all those ad-hoc rules. The net actual effect on the current contents of postgres.bki is that some fields that had been quoted despite containing only digits or only "-" lose their unnecessary quotes. Also, now that genbki.pl will always quote values containing a backslash, there's no need for bootscanner.l to allow unquoted octal escapes; so simplify its production for "id" by removing that possibility. John Naylor, slightly modified by me Discussion: https://postgr.es/m/CAJVSVGUNao=-Q2-vAN3PYcdF5tnL5JAHwGwzZGuYHtq+Mk_9ng@mail.gmail.com
* Fix confusion on the padding of GIDs in on commit and abort records.Heikki Linnakangas2018-04-17
| | | | | | | | | | | Review of commit 1eb6d652: It's pointless to add padding to the GID fields, when the code that follows assumes that there is no alignment, and uses memcpy(). Remove the pointless padding. Update comments to note the new fields in the WAL records. Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/33b787bf-dc20-1161-54e9-3f3b607bf59d%40iki.fi
* Update Append's idea of first_partial_planAlvaro Herrera2018-04-17
| | | | | | | | | | | | It turns out that after runtime partition pruning, Append's first_partial_plan does not accurately represent partial plans to run, if any of those got pruned. This could limit participation of workers in some partial subplans, if other subplans got pruned. Fix it by keeping an index of the first valid partial subplan in the state node, determined at execnode Init time. Author: David Rowley, with cosmetic changes by me. Discussion: https://postgr.es/m/CAKJS1f8o2Yd=rOP=Et3A0FWgF+gSAOkFSU6eNhnGzTPV7nN8sQ@mail.gmail.com
* Fix a few typos in comments and variable names.Heikki Linnakangas2018-04-17
| | | | | Author: Michael Paquier Discussion: https://www.postgresql.org/message-id/20180411075223.GB19732%40paquier.xyz
* Improve coverage of nodeAppend runtime partition pruneAlvaro Herrera2018-04-17
| | | | | | | | | | | | | | | | | coverage report indicated that mark_invalid_subplans_as_finished() and nearby code was not getting exercised by any tests. Add a new one which has execution-time Params rather than only external Params to fix this. In passing, David noticed that ab_q6 tests were not actually required to have a generic plan. The tests were testing exec Params not external Params, so there was no need for the PREPARE. Remove the PREPARE, making these plain queries. (The new queries are called from explain_parallel_append, which may be unnecessary since they don't actually have a Parallel Append node, just an Append. But it doesn't seem to hurt anything, either.) Author: David Rowley Discussion: https://postgr.es/m/CAKJS1f--hopb6JBSDY4wiXTS3ZcDp-wparXjTQ1nzNdBa04Fog@mail.gmail.com
* Add more infinite recursion detection while locking a view.Tatsuo Ishii2018-04-17
| | | | | Also add regression test cases for detecting infinite recursion in locking view tests. Some document enhancements. Patch by Yugo Nagata.
* Restore partition_prune's usage of parallel workersAlvaro Herrera2018-04-16
| | | | | | | | This reverts commit 4d0f6d3f207d ("Attempt to stabilize partition_prune test output (2)"), and attempts to stabilize the test by using string replacement to hide any loop count difference in parallel nodes. Discussion: https://postgr.es/m/4475.1523628300@sss.pgh.pa.us
* Fix broken collation-aware searches in SP-GiST text opclass.Tom Lane2018-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | spg_text_leaf_consistent() supposed that it should compare only Min(querylen, entrylen) bytes of the two strings, and then deal with any excess bytes in one string or the other by assuming the longer string is greater if the prefixes are equal. Quite aside from the fact that that's just wrong in some locales (e.g., 'ch' is not less than 'd' in cs_CZ), it also risked passing incomplete multibyte characters to strcoll(), with ensuing bad results. Instead, just pass the full strings to varstr_cmp, and let it decide what to do about unequal-length strings. Fortunately, this error doesn't imply any index corruption, it's just that searches might return the wrong set of entries. Per report from Emre Hasegeli, though this is not his patch. Thanks to Peter Geoghegan for review and discussion. This code was born broken, so back-patch to all supported branches. In HEAD, I failed to resist the temptation to do a bit of cosmetic cleanup/pgindent'ing on 710d90da1, too. Discussion: https://postgr.es/m/CAE2gYzzb6K51VnTq5i5p52z+j9p2duEa-K1T3RrC_GQEynAKEg@mail.gmail.com
* Update expected output of new testAlvaro Herrera2018-04-16
| | | | | | Forgot to 'git add' the file after tweaking the test as submitted :-( Per buildfarm
* Ignore whole-rows in INSERT/CONFLICT with partitioned tablesAlvaro Herrera2018-04-16
| | | | | | | | | | | | | | | | We had an Assert() preventing whole-row expressions from being used in the SET clause of INSERT ON CONFLICT, but it seems unnecessary, given some tests, so remove it. Add a new test to exercise the case. Still at ExecInitPartitionInfo, we used map_partition_varattnos (which constructs an attribute map, then calls map_variable_attnos) using the same two relations many times in different expressions and with different parameters. Constructing the map over and over is a waste. To avoid this repeated work, construct the map once, and use map_variable_attnos() directly instead. Author: Amit Langote, per comments by me (Álvaro) Discussion: https://postgr.es/m/20180326142016.m4st5e34chrzrknk@alvherre.pgsql
* Clean up callers of JsonbIteratorNext().Tom Lane2018-04-15
| | | | | | | | | | | | | Coverity complained about the lack of a check on the return value in parse_jsonb_index_flags' last call of JsonbIteratorNext. Seems like a reasonable gripe to me, especially since the code is depending on that being WJB_DONE to not leak memory, so add a check. In passing, improve a couple other places where the result was being ignored, either by adding an assert or at least a cast to void. Also, don't spell "WJB_DONE" as "0". That's horrid coding style, and it wasn't consistent either.
* Don't attempt to verify checksums on new pagesMagnus Hagander2018-04-15
| | | | | | | Teach both base backups and pg_verify_checksums that if a page is new, it does not have a checksum yet, so it shouldn't be verified. Noted by Tomas Vondra, review by David Steele.
* Remove -f option from pg_verify_checksumsMagnus Hagander2018-04-15
| | | | | | | | This option makes no sense when the cluster checksum state cannot be changed, and should have been removed in the revert. Author: Daniel Gustafsson Review: Michael Paquier
* Simplify view-expansion code in rewriteHandler.c.Tom Lane2018-04-14
| | | | | | | | | | | | | | | | | | | In the wake of commit 50c6bb022, it's not necessary for ApplyRetrieveRule to have a forUpdatePushedDown parameter. By the time control gets here for any given view-referencing RTE, we should already have pushed down the effects of any FOR UPDATE/SHARE clauses affecting the view from outer query levels. Hence if we don't find a RowMarkClause at the current query level, that's sufficient proof that there is no outer one either. This in turn means we need no forUpdatePushedDown parameter for fireRIRrules. I wonder whether we oughtn't also revert commit cba2d2717, since it now seems likely that that was band-aiding around the bad effects of doing FOR UPDATE pushdown and view expansion in the wrong order. However, in the absence of evidence that the current coding of markQueryForLocking is actually buggy (i.e. missing RTEs it ought to mark), it seems best to leave it alone. Discussion: https://postgr.es/m/24db7b8f-3de5-e25f-7ab9-d8848351d42c@gmail.com
* List src/include/partitioning in src/include/MakefileAlvaro Herrera2018-04-14
| | | | | | This omission prevented partitioning header files from being installed. Per buildfarm member crake.
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-25 12:13:30 +0000