aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Fix handling of pgbench's hash when no argument is providedMichael Paquier2018-07-27
| | | | | | | | | Depending on the platform used, this can cause a crash in the worst case, or an unhelpful error message, so fail gracefully. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.21.1807262302550.29874@lancre Backpatch: 11-, where hash() has been added in pgbench.
* Provide plpgsql tests for cases involving record field changes.Tom Lane2018-07-26
| | | | | | | | | | | | | | We suppressed one of these test cases in commit feb1cc559 because it was failing to produce the expected results on CLOBBER_CACHE_ALWAYS buildfarm members. But now we need another test with similar behavior, so let's set up a test file that is expected to vary between regular and CLOBBER_CACHE_ALWAYS cases, and provide variant expected files. Someday we should fix plpgsql's failure for change-of-field-type, and then the discrepancy will go away and we can fold these tests back into plpgsql_record.sql. But today is not that day. Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk
* Avoid crash in eval_const_expressions if a Param's type changes.Tom Lane2018-07-26
| | | | | | | | | | | | | | | | | | | | | | | | Since commit 6719b238e it's been possible for the values of plpgsql record field variables to be exposed to the planner as Params. (Before that, plpgsql never supplied values for such variables during planning, so that the problematic code wasn't reached.) Other places that touch potentially-type-mutable Params either cope gracefully or do runtime-test-and-ereport checks that the type is what they expect. But eval_const_expressions() just had an Assert, meaning that it either failed the assertion or risked crashes due to using an incompatible value. In this case, rather than throwing an ereport immediately, we can just not perform a const-substitution in case of a mismatch. This seems important for the same reason that the Param fetch was speculative: we might not actually reach this part of the expression at runtime. Test case will follow in a separate commit. Patch by me, pursuant to bug report from Andrew Gierth. Back-patch to v11 where the previous commit appeared. Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk
* LLVMJIT: Release JIT context after running ExprContext shutdown callbacks.Andres Freund2018-07-25
| | | | | | | | | | | | Due to inlining it previously was possible that an ExprContext's shutdown callback pointed to a JITed function. As the JIT context previously was shut down before the shutdown callbacks were called, that could lead to segfaults. Fix the ordering. Reported-By: Dmitry Dolgov Author: Andres Freund Discussion: https://postgr.es/m/CA+q6zcWO7CeAJtHBxgcHn_hj+PenM=tvG0RJ93X1uEJ86+76Ug@mail.gmail.com Backpatch: 11-, where JIT compilation was added
* LLVMJIT: Check for 'noinline' attribute in recursively inlined functions.Andres Freund2018-07-25
| | | | | | | | | | | | Previously the attribute was only checked for external functions inlined, not "static" functions that had to be inlined as dependencies. This isn't really a bug, but makes debugging a bit harder. The new behaviour also makes more sense. Therefore backpatch. Author: Andres Freund Backpatch: 11-, where JIT compilation was added
* Pad semaphores to avoid false sharing.Thomas Munro2018-07-25
| | | | | | | | | | | | | | | | | | | In a USE_UNNAMED_SEMAPHORES build, the default on Linux and FreeBSD since commit ecb0d20a, we have an array of sem_t objects. This turned out to reduce performance compared to the previous default USE_SYSV_SEMAPHORES on an 8 socket system. Testing showed that the lost performance could be regained by padding the array elements so that they have their own cache lines. This matches what we do for similar hot arrays (see LWLockPadded, WALInsertLockPadded). Back-patch to 10, where unnamed semaphores were adopted as the default semaphore interface on those operating systems. Author: Thomas Munro Reviewed-by: Andres Freund Reported-by: Mithun Cy Tested-by: Mithun Cy, Tom Lane, Thomas Munro Discussion: https://postgr.es/m/CAD__OugYDM3O%2BdyZnnZSbJprSfsGFJcQ1R%3De59T3hcLmDug4_w%40mail.gmail.com
* psql: Add option for procedures to \dfPeter Eisentraut2018-07-24
|
* Fix calculation for WAL segment recycling and removalMichael Paquier2018-07-24
| | | | | | | | | | | | | | Commit 4b0d28de06 has removed the prior checkpoint and related facilities but has left WAL recycling based on the LSN of the prior checkpoint, which causes incorrect calculations for WAL removal and recycling for max_wal_size and min_wal_size. This commit changes things so as the base calculation point is the last checkpoint generated. Reported-by: Kyotaro Horiguchi Author: Kyotaro Horiguchi Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20180723.135748.42558387.horiguchi.kyotaro@lab.ntt.co.jp Backpatch: 11-, where the prior checkpoint has been removed.
* pgbench: Remove duplicate entries from table of builtin functions.Robert Haas2018-07-23
| | | | | | Fabien Coelho Discussion: http://postgr.es/m/alpine.DEB.2.21.1807221822320.19939@lancre
* LLVMJIT: Adapt to API changes in gdb and perf support.Andres Freund2018-07-22
| | | | | | | | | | During the work of upstreaming my previous patches for gdb and perf support the API changed. Adapt. Normally this wouldn't necessarily be something to backpatch, but the previous API wasn't upstream, and at least the gdb support is quite useful for debugging. Author: Andres Freund Backpatch: 11, where LLVM based JIT support was added.
* LLVMJIT: Fix LLVM build for LLVM > 7.Andres Freund2018-07-22
| | | | | | | The location of LLVMAddPromoteMemoryToRegisterPass moved. Author: Andres Freund Backpatch: 11, where LLVM based JIT support was added.
* Reset context at the tail end of JITed EEOP_AGG_PLAIN_TRANS.Andres Freund2018-07-22
| | | | | | | | | | While no negative consequences are currently known, it's clearly wrong to not reset the context in one of the branches. Reported-By: Dmitry Dolgov Author: Dmitry Dolgov Discussion: https://postgr.es/m/CAGPqQf165-=+Drw3Voim7M5EjHT1zwPF9BQRjLFQzCzYnNZEiQ@mail.gmail.com Backpatch: 11-, where JIT compilation support was added
* Fix JITed EEOP_AGG_INIT_TRANS, which missed some state.Andres Freund2018-07-22
| | | | | | | | | | | | The JIT compiled implementation missed maintaining AggState->{current_set,curaggcontext}. That could lead to trouble because the transition value could be allocated in the wrong context. Reported-By: Rushabh Lathia Diagnosed-By: Dmitry Dolgov Author: Dmitry Dolgov, with minor changes by me Discussion: https://postgr.es/m/CAGPqQf165-=+Drw3Voim7M5EjHT1zwPF9BQRjLFQzCzYnNZEiQ@mail.gmail.com Backpatch: 11-, where JIT compilation support was added
* Further portability hacking in pg_upgrade's test script.Tom Lane2018-07-21
| | | | | | | | | | | | | | | | | | | | | | I blew the dust off a Bourne shell (file date 1996, yea verily) and tried to run test.sh with it. It mostly worked, but I found that the temp-directory creation code introduced by commit be76a6d39 was not compatible, for a couple of reasons: this shell thinks "set -e" should force an exit if a command within backticks fails, and it also thinks code within braces should be executed by a sub-shell, meaning that variable settings don't propagate back up to the parent shell. In view of Victor Wagner's report that Solaris is still using pre-POSIX shells, seems like we oughta make this case work. It's not like the code is any less idiomatic this way; the prior coding technique appeared nowhere else. (There is a remaining bash-ism here, which is that $RANDOM doesn't do what the code hopes in non-bash shells. But the use of $$ elsewhere in that path should be enough to ensure uniqueness and some amount of randomness, so I think it's okay as-is.) Back-patch to all supported branches, as the previous commit was. Discussion: https://postgr.es/m/20180720153820.69e9ae6c@fafnir.local.vm
* Be more paranoid about quoting in pg_upgrade's test script.Tom Lane2018-07-21
| | | | | | | | | | | | | Double-quote $PGDATA in "find" commands introduced by commit da9b580d8, in case that path contains spaces or other special characters. Adjust a few other places so that quoting is done more consistently. None of the others are actual bugs AFAICS, but it's confusing to readers if the same thing is done differently in different places. Noted by Tels. Discussion: https://postgr.es/m/c96303c04c360bbedaa04f90f515745b.squirrel@sm.webmail.pair.com
* Avoid unportable shell syntax in pg_upgrade's test script.Tom Lane2018-07-20
| | | | | | | | | | Most of test.sh uses traditional backtick syntax for command substitution, but commit da9b580d8 introduced two uses of $(...) syntax, which is not recognized by very old shells. Bring those into line with the rest. Victor Wagner Discussion: https://postgr.es/m/20180720153820.69e9ae6c@fafnir.local.vm
* Guard against rare RAND_bytes() failures in pg_strong_random().Dean Rasheed2018-07-20
| | | | | | | | | | | | | | | | | | | When built using OpenSSL, pg_strong_random() uses RAND_bytes() to generate the random number. On very rare occasions that can fail, if its PRNG has not been seeded with enough data. Additionally, once it does fail, all subsequent calls will also fail until more seed data is added. Since this is required during backend startup, this can result in all new backends failing to start until a postmaster restart. Guard against that by checking the state of OpenSSL's PRNG using RAND_status(), and if necessary (very rarely), seeding it using RAND_poll(). Back-patch to v10, where pg_strong_random() was introduced. Dean Rasheed and Michael Paquier. Discussion: https://postgr.es/m/CAEZATCXMtxbzSAvyKKk5uCRf9pNt4UV%2BF_5v%3DgLfJUuPxU4Ytg%40mail.gmail.com
* Fix handling of empty uncompressed posting list pages in GINAlexander Korotkov2018-07-19
| | | | | | | | | | | | | | PostgreSQL 9.4 introduces posting list compression in GIN. This feature supports online upgrade, so that after pg_upgrade uncompressed posting lists are compressed on-the-fly. Underlying code appears to always expect at least one item on uncompressed posting list page. But there could be completely empty pages, because VACUUM never deletes leftmost and rightmost pages from posting trees. This commit fixes that. Reported-by: Sivasubramanian Ramasubramanian Discussion: https://postgr.es/m/1531867212836.63354%40amazon.com Author: Sivasubramanian Ramasubramanian, Alexander Korotkov Backpatch-through: 9.4
* Remove undocumented restriction against duplicate partition key columns.Tom Lane2018-07-19
| | | | | | | | | | | | | | | | | | | transformPartitionSpec rejected duplicate simple partition columns (e.g., "PARTITION BY RANGE (x,x)") but paid no attention to expression columns, resulting in inconsistent behavior. Worse, cases like "PARTITION BY RANGE (x,(x))") were accepted but would then result in dump/reload failures, since the expression (x) would get simplified to a plain column later. There seems no better reason for this restriction than there was for the one against duplicate included index columns (cf commit 701fd0bbc), so let's just remove it. Back-patch to v10 where this code was added. Report and patch by Yugo Nagata. Discussion: https://postgr.es/m/20180712165939.36b12aff.nagata@sraoss.co.jp
* Improve psql's \d command to show whether index columns are key columns.Tom Lane2018-07-19
| | | | | | | | | | | | | | | | | This is essential information when looking at an index that has "included" columns. Per discussion, follow the style used in \dC and some other places: column header is "Key?" and values are "yes" or "no" (all translatable). While at it, revise describeOneTableDetails to be a bit more maintainable: avoid hard-wired column numbers and multiple repetitions of what needs to be identical test logic. This also results in the emitted catalog query corresponding more closely to what we print, which should be a benefit to users of ECHO_HIDDEN mode, and perhaps a bit faster too (the old logic sometimes asked for values it would not print, even ones that are fairly expensive to get). Discussion: https://postgr.es/m/21724.1531943735@sss.pgh.pa.us
* Fix pg_get_indexdef()'s behavior for included index columns.Tom Lane2018-07-19
| | | | | | | | | | | | | | | | | The multi-argument form of pg_get_indexdef() failed to print anything when asked to print a single index column that is an included column rather than a key column. This seems an unintentional result of someone having tried to take a short-cut and use the attrsOnly flag for two different purposes. To fix, split said flag into two flags, attrsOnly which suppresses non-attribute info, and keysOnly which suppresses included columns. Add a test case using psql's \d command, which relies on that function. (It's mighty tempting at this point to replace pg_get_indexdef_worker's mess of boolean flag arguments with a single bitmask-of-flags argument, which would allow making the call sites much more self-documenting. But I refrained for the moment.) Discussion: https://postgr.es/m/21724.1531943735@sss.pgh.pa.us
* Rewrite comments in replication slot advance implementationAlvaro Herrera2018-07-19
| | | | | | | | | | | | The code added by 9c7d06d60680 was a bit obscure; clarify that by rewriting the comments. Lack of clarity has already caused bugs, so it's a worthy goal. Co-authored-by: Arseny Sher <a.sher@postgrespro.ru> Co-authored-by: Michaël Paquier <michael@paquier.xyz> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Petr Jelínek <petr.jelinek@2ndquadrant.com> Discussion: https://postgr.es/m/87y3fgoyrn.fsf@ars-thinkpad
* Fix error message when a hostaddr cannot be parsed.Heikki Linnakangas2018-07-19
| | | | | | | | | | | | | | We were incorrectly passing hostname, not hostaddr, in the error message, and because of that, you got: $ psql 'hostaddr=foo' psql: could not parse network address "(null)": Name or service not known Backpatch to v10, where this was broken (by commit 7b02ba62e9). Report and fix by Robert Haas. Discussion: https://www.postgresql.org/message-id/CA+TgmoapFQA30NomGKEaZCu3iN7mF7fux8fbbk9SouVOT2JP7w@mail.gmail.com
* Rephrase a few comments for clarity.Heikki Linnakangas2018-07-19
| | | | | | | | I was confused by what "intended to be parallel serially" meant, until Robert Haas and David G. Johnston explained it. Rephrase the comment to make it more clear, using David's suggested wording. Discussion: https://www.postgresql.org/message-id/1fec9022-41e8-e484-70ce-2179b08c2092%40iki.fi
* Fix print of Path nodes when using OPTIMIZER_DEBUGMichael Paquier2018-07-19
| | | | | | | | | | | GatherMergePath (introduced in 10) and CustomPath (introduced in 9.5) have gone missing. The order of the Path nodes was inconsistent with what is listed in nodes.h, so make the order consistent at the same time to ease future checks and additions. Author: Sawada Masahiko Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAD21AoBQMLoc=ohH-oocuAPsELrmk8_EsRJjOyR8FQLZkbE0wA@mail.gmail.com
* Fix re-parameterize of MergeAppendPathMichael Paquier2018-07-19
| | | | | | | | | | | | | Instead of MergeAppendPath, MergeAppend nodes were considered. This code is not covered by any tests now, which should be addressed at some point. This is an oversight from f49842d, which introduced partition-wise joins in v11, so back-patch down to that. Author: Michael Paquier Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/20180718062202.GC8565@paquier.xyz
* Remove race-prone hot_standby_feedback test cases in 001_stream_rep.pl.Tom Lane2018-07-18
| | | | | | | | | | | | | | | | | | | | | | This script supposed that if it turned hot_standby_feedback on and then shut down the standby server, at least one feedback message would be guaranteed to be sent before the standby stops. But there is no such guarantee, if the standby's walreceiver process is slow enough --- and we've seen multiple failures in the buildfarm showing that that does happen in practice. While we could rearrange the walreceiver logic to make it less likely, it seems probably impossible to create a really bulletproof guarantee of that sort; and if we tried, we might create situations where the walreceiver wouldn't react in a timely manner to shutdown commands. It seems better instead to remove the script's assumption that feedback will occur before shutdown. But once we do that, these last few tests seem quite redundant with the earlier tests in the script. So let's just drop them altogether and save some buildfarm cycles. Backpatch to v10 where these tests were added. Discussion: https://postgr.es/m/1922.1531592205@sss.pgh.pa.us
* Drop the rule against included index columns duplicating key columns.Tom Lane2018-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
* Fix misc typos, mostly in comments.Heikki Linnakangas2018-07-18
| | | | | | | | A collection of typos I happened to spot while reading code, as well as grepping for common mistakes. Backpatch to all supported versions, as applicable, to avoid conflicts when backporting other commits in the future.
* Fix ALTER TABLE...SET STATS error message for included columnsAlvaro Herrera2018-07-16
| | | | | | | | | | The existing error message was complaining that the column is not an expression, which is not correct. Introduce a suitable wording variation and a test. Co-authored-by: Yugo Nagata <nagata@sraoss.co.jp> Discussion: https://postgr.es/m/20180628182803.e4632d5a.nagata@sraoss.co.jp Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
* Fix partition pruning with IS [NOT] NULL clausesAlvaro Herrera2018-07-16
| | | | | | | | | | | | | | | The original code was unable to prune partitions that could not possibly contain NULL values, when the query specified less than all columns in a multicolumn partition key. Reorder the if-tests so that it is, and add more commentary and regression tests. Reported-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Co-authored-by: Dilip Kumar <dilipbalaut@gmail.com> Co-authored-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: amul sul <sulamul@gmail.com> Discussion: https://postgr.es/m/CAFjFpRc7qjLUfXLVBBC_HAnx644sjTYM=qVoT3TJ840HPbsTXw@mail.gmail.com
* Add subtransaction handling for table synchronization workers.Robert Haas2018-07-16
| | | | | | | | | | | Since the old logic was completely unaware of subtransactions, a change made in a subsequently-aborted subtransaction would still cause workers to be stopped at toplevel transaction commit. Fix that by managing a stack of worker lists rather than just one. Amit Khandekar and Robert Haas Discussion: http://postgr.es/m/CAJ3gD9eaG_mWqiOTA2LfAug-VRNn1hrhf50Xi1YroxL37QkZNg@mail.gmail.com
* doc: Update redirecting linksPeter Eisentraut2018-07-16
| | | | | | | Update links that resulted in redirects. Most are changes from http to https, but there are also some other minor edits. (There are still some redirects where the target URL looks less elegant than the one we currently have. I have left those as is.)
* Fix hashjoin costing mistake introduced with inner_unique optimization.Tom Lane2018-07-14
| | | | | | | | | | | | | | | | | | | | | | | In final_cost_hashjoin(), commit 9c7f5229a allowed inner_unique cases to follow a code path previously used only for SEMI/ANTI joins; but it neglected to fix an if-test within that path that assumed SEMI and ANTI were the only possible cases. This resulted in a wrong value for hashjointuples, and an ensuing bad cost estimate, for inner_unique normal joins. Fortunately, for inner_unique normal joins we can assume the number of joined tuples is the same as for a SEMI join; so there's no need for more code, we just have to invert the test to check for ANTI not SEMI. It turns out that in two contrib tests in which commit 9c7f5229a changed the plan expected for a query, the change was actually wrong and induced by this estimation error, not by any real improvement. Hence this patch also reverts those changes. Per report from RK Korlapati. Backpatch to v10 where the error was introduced. David Rowley Discussion: https://postgr.es/m/CA+SNy03bhq0fodsfOkeWDCreNjJVjsdHwUsb7AG=jpe0PtZc_g@mail.gmail.com
* Update documentation editor setup instructionsPeter Eisentraut2018-07-13
| | | | | | | | | | | | Now that the documentation sources are in XML rather than SGML, some of the documentation about the editor, or more specifically Emacs, setup needs updating. The updated instructions recommend using nxml-mode, which works mostly out of the box, with some small tweaks in emacs.samples and .dir-locals.el. Also remove some obsolete stuff in .dir-locals.el. I did, however, leave the sgml-mode settings in there so that someone using Emacs without emacs.samples gets those settings when editing a *.sgml file.
* Fix crash in json{b}_populate_recordset() and json{b}_to_recordset().Tom Lane2018-07-13
| | | | | | | | | | | | | | | | | As of commit 37a795a60, populate_recordset_worker() tried to pass back (as rsi.setDesc) a tupdesc that it also had cached in its fn_extra. But the core executor would free the passed-back tupdesc, risking a crash if the function were called again in the same query. The safest and least invasive way to fix that is to make an extra tupdesc copy to pass back. While at it, I failed to resist the temptation to get rid of unnecessary get_fn_expr_argtype() calls here and in populate_record_worker(). Per report from Dmitry Dolgov; thanks to Michael Paquier and Andrew Gierth for investigation and discussion. Discussion: https://postgr.es/m/CA+q6zcWzN9ztCfR47ZwgTr1KLnuO6BAY6FurxXhovP4hxr+yOQ@mail.gmail.com
* Dump foreign keys on partitioned tablesAlvaro Herrera2018-07-13
| | | | | | | | | | | | | | | The patch that ended up as commit 3de241dba86f ("Foreign keys on partitioned tables") lacked pg_dump tests, so the pg_dump code that was there to support it inadvertently stopped working when in later development I modified the backend code not to emit pg_trigger rows for the partitioned table itself. Bug analysis and code fix is by Michaël. I (Álvaro) added the test. Reported-by: amul sul <sulamul@gmail.com> Co-authored-by: Michaël Paquier <michael@paquier.xyz> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/CAAJ_b94n=UsNVhgs97vCaWEZAMe-tGDRVuZ73oePQH=eaJKGSA@mail.gmail.com
* Fix inadequate buffer locking in FSM and VM page re-initialization.Tom Lane2018-07-13
| | | | | | | | | | | | | | | | | | | When reading an existing FSM or VM page that was found to be corrupt by the buffer manager, the code applied PageInit() to reinitialize the page, but did so without any locking. There is thus a hazard that two backends might concurrently do PageInit, which in itself would still be OK, but the slower one might then zero over subsequent data changes applied by the faster one. Even that is unlikely to be fatal; but it's not desirable, so add locking to prevent it. This does not add any locking overhead in the normal code path where the page is OK. It's not immediately obvious that that's safe, but I believe it is, for reasons explained in the added comments. Problem noted by R P Asim. It's been like this for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com
* Prohibit transaction commands in security definer proceduresPeter Eisentraut2018-07-13
| | | | | | | | | | | Starting and aborting transactions in security definer procedures doesn't work. StartTransaction() insists that the security context stack is empty, so this would currently cause a crash, and AbortTransaction() resets it. This could be made to work by reorganizing the code, but right now we just prohibit it. Reported-by: amul sul <sulamul@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b96Gupt_LFL7uNyy3c50-wbhA68NUjiK5%3DrF6_w%3Dpq_T%3DQ%40mail.gmail.com
* Reset shmem_exit_inprogress after shmem_exit()Peter Eisentraut2018-07-12
| | | | | | | | | In ad9a274778d2d88c46b90309212b92ee7fdf9afe, shmem_exit_inprogress was introduced. But we need to reset it after shmem_exit(), because unlike the similar proc_exit(), shmem_exit() can also be called for cleanup when the process will not exit. Reported-by: Andrew Gierth <andrew@tao11.riddles.org.uk>
* Fix FK checks of TRUNCATE involving partitioned tablesAlvaro Herrera2018-07-12
| | | | | | | | | | | | | When truncating a table that is referenced by foreign keys in partitioned tables, the check to ensure the referencing table are also truncated spuriously failed. This is because it was relying on relhastriggers as a proxy for the table having FKs, and that's wrong for partitioned tables. Fix it to consider such tables separately. There may be a better way ... but this code is pretty inefficient already. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/20180711000624.zmeizicibxeehhsg@alvherre.pgsql
* Allow using the updated tuple while moving it to a different partition.Amit Kapila2018-07-12
| | | | | | | | | | | | | | | | | | An update that causes the tuple to be moved to a different partition was missing out on re-constructing the to-be-updated tuple, based on the latest tuple in the update chain. Instead, it's simply deleting the latest tuple and inserting a new tuple in the new partition based on the old tuple. Commit 2f17844104 didn't consider this case, so some of the updates were getting lost. In passing, change the argument order for output parameter in ExecDelete and add some commentary about it. Reported-by: Pavan Deolasee Author: Amit Khandekar, with minor changes by me Reviewed-by: Dilip Kumar, Amit Kapila and Alvaro Herrera Backpatch-through: 11 Discussion: https://postgr.es/m/CAJ3gD9fRbEzDqdeDq1jxqZUb47kJn+tQ7=Bcgjc8quqKsDViKQ@mail.gmail.com
* Make logical WAL sender report streaming state appropriatelyMichael Paquier2018-07-12
| | | | | | | | | | | | | | | | | | | | WAL senders sending logically-decoded data fail to properly report in "streaming" state when starting up, hence as long as one extra record is not replayed, such WAL senders would remain in a "catchup" state, which is inconsistent with the physical cousin. This can be easily reproduced by for example using pg_recvlogical and restarting the upstream server. The TAP tests have been slightly modified to detect the failure and strengthened so as future tests also make sure that a node is in streaming state when waiting for its catchup. Backpatch down to 9.4 where this code has been introduced. Reported-by: Sawada Masahiko Author: Simon Riggs, Sawada Masahiko Reviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran Discussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com
* Fix create_scan_plan's handling of sortgrouprefs for physical tlists.Tom Lane2018-07-11
| | | | | | | | | | | | | | | | | | | | | | | | We should only run apply_pathtarget_labeling_to_tlist if CP_LABEL_TLIST was specified, because only in that case has use_physical_tlist checked that the labeling will succeed; otherwise we may get an "ORDER/GROUP BY expression not found in targetlist" error. (This subsumes the previous test about gating_clauses, because we reset "flags" to zero earlier if there are gating clauses to apply.) The only known case in which a failure can occur is with a ProjectSet path directly atop a table scan path, although it seems likely that there are other cases or will be such in future. This means that the failure is currently only visible in the v10 branch: 9.6 didn't have ProjectSet, while in v11 and HEAD, apply_scanjoin_target_to_paths for some weird reason is using create_projection_path not apply_projection_to_path, masking the problem because there's a ProjectionPath in between. Nonetheless this code is clearly wrong on its own terms, so back-patch to 9.6 where this logic was introduced. Per report from Regina Obe. Discussion: https://postgr.es/m/001501d40f88$75186950$5f493bf0$@pcorp.us
* Fix bugs with degenerate window ORDER BY clauses in GROUPS/RANGE mode.Tom Lane2018-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nodeWindowAgg.c failed to cope with the possibility that no ordering columns are defined in the window frame for GROUPS mode or RANGE OFFSET mode, leading to assertion failures or odd errors, as reported by Masahiko Sawada and Lukas Eder. In RANGE OFFSET mode, an ordering column is really required, so add an Assert about that. In GROUPS mode, the code would work, except that the node initialization code wasn't in sync with the execution code about when to set up tuplestore read pointers and spare slots. Fix the latter for consistency's sake (even though I think the changes described below make the out-of-sync cases unreachable for now). Per SQL spec, a single ordering column is required for RANGE OFFSET mode, and at least one ordering column is required for GROUPS mode. The parser enforced the former but not the latter; add a check for that. We were able to reach the no-ordering-column cases even with fully spec compliant queries, though, because the planner would drop partitioning and ordering columns from the generated plan if they were redundant with earlier columns according to the redundant-pathkey logic, for instance "PARTITION BY x ORDER BY y" in the presence of a "WHERE x=y" qual. While in principle that's an optimization that could save some pointless comparisons at runtime, it seems unlikely to be meaningful in the real world. I think this behavior was not so much an intentional optimization as a side-effect of an ancient decision to construct the plan node's ordering-column info by reverse-engineering the PathKeys of the input path. If we give up redundant-column removal then it takes very little code to generate the plan node info directly from the WindowClause, ensuring that we have the expected number of ordering columns in all cases. (If anyone does complain about this, the planner could perhaps be taught to remove redundant columns only when it's safe to do so, ie *not* in RANGE OFFSET mode. But I doubt anyone ever will.) With these changes, the WindowAggPath.winpathkeys field is not used for anything anymore, so remove it. The test cases added here are not actually very interesting given the removal of the redundant-column-removal logic, but they would represent important corner cases if anyone ever tries to put that back. Tom Lane and Masahiko Sawada. Back-patch to v11 where RANGE OFFSET and GROUPS modes were added. Discussion: https://postgr.es/m/CAD21AoDrWqycq-w_+Bx1cjc+YUhZ11XTj9rfxNiNDojjBx8Fjw@mail.gmail.com Discussion: https://postgr.es/m/153086788677.17476.8002640580496698831@wrigleys.postgresql.org
* Block replication slot advance for these not yet reserving WALMichael Paquier2018-07-11
| | | | | | | | | | | | | | | | Such replication slots are physical slots freshly created without WAL being reserved, which is the default behavior, which have not been used yet as WAL consumption resources to retain WAL. This prevents advancing a slot to a position older than any WAL available, which could falsify calculations for WAL segment recycling. This also cleans up a bit the code, as ReplicationSlotRelease() would be called on ERROR, and improves error messages. Reported-by: Kyotaro Horiguchi Author: Michael Paquier Reviewed-by: Andres Freund, Álvaro Herrera, Kyotaro Horiguchi Discussion: https://postgr.es/m/20180626071305.GH31353@paquier.xyz
* Better handle pseudotypes as partition keysAlvaro Herrera2018-07-10
| | | | | | | | | | | | | | | | | | | | | | We fail to handle polymorphic types properly when they are used as partition keys: we were unnecessarily adding a RelabelType node on top, which confuses code examining the nodes. In particular, this makes predtest.c-based partition pruning not to work, and ruleutils.c to emit expressions that are uglier than needed. Fix it by not adding RelabelType when not needed. In master/11 the new pruning code is separate so it doesn't suffer from this problem, since we already fixed it (in essentially the same way) in e5dcbb88a15d, which also added a few tests; back-patch those tests to pg10 also. But since UPDATE/DELETE still uses predtest.c in pg11, this change improves partitioning for those cases too. Add tests for this. The ruleutils.c behavior change is relevant in pg11/master too. Co-authored-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/54745d13-7ed4-54ac-97d8-ea1eec95ae25@lab.ntt.co.jp
* Fix typosPeter Eisentraut2018-07-10
|
* Fix typoPeter Eisentraut2018-07-10
|
* Avoid emitting a bogus WAL record when recycling an all-zero btree page.Tom Lane2018-07-09
| | | | | | | | | | | | | | | | | | | | Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for a page that it was about to recycle. However, it failed to distinguish all-zero pages from dead pages, which is important because only the latter have valid btpo.xact values, or indeed any special space at all. Recycling an all-zero page with XLogStandbyInfoActive() enabled therefore led to an Assert failure, or to emission of a WAL record containing a bogus cutoff XID, which might lead to unnecessary query cancellations on hot standby servers. Per reports from Antonin Houska and 自己. Amit Kapila was first to propose this fix, and Robert Haas, myself, and Kyotaro Horiguchi reviewed it at various times. This is an old bug, so back-patch to all supported branches. Discussion: https://postgr.es/m/2628.1474272158@localhost Discussion: https://postgr.es/m/48875502.f4a0.1635f0c27b0.Coremail.zoulx1982@163.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-23 13:19:50 +0000