aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Further -Wimplicit-fallthrough cleanup.Andres Freund2018-05-01
| | | | | | | | | | | Tom's earlier commit in 41c912cad159 didn't update a few cases that are only encountered with the non-standard --with-llvm config flag. Additionally there's also one case that appears to be a deficiency in gcc's (up to trunk as of a few days ago) detection of "fallthrough" comments - changing the placement slightly fixes that. Author: Andres Freund Discussion: https://postgr.es/m/20180502003239.wfnqu7ekz7j7imm4@alap3.anarazel.de
* Fix some assorted compiler warnings on Windows.Tom Lane2018-05-01
| | | | | | | | | | Don't overflow the result type of constant expressions. Don't negate unsigned types. Define HAVE_STDBOOL_H for Visual C++ 2013 and later. Thomas Munro Reviewed-By: Michael Paquier and Tom Lane Discussion: https://postgr.es/m/CAEepm%3D3%3DTDYEXUEcHpEx%2BTwc31wo7PA0oBAiNt6sWmq93MW02A%40mail.gmail.com
* Clean up warnings from -Wimplicit-fallthrough.Tom Lane2018-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | Recent gcc can warn about switch-case fall throughs that are not explicitly labeled as intentional. This seems like a good thing, so clean up the warnings exposed thereby by labeling all such cases with comments that gcc will recognize. In files that already had one or more suitable comments, I generally matched the existing style of those. Otherwise I went with /* FALLTHROUGH */, which is one of the spellings approved at the more-restrictive-than-default level -Wimplicit-fallthrough=4. (At the default level you can also spell it /* FALL ?THRU */, and it's not picky about case. What you can't do is include additional text in the same comment, so some existing comments containing versions of this aren't good enough.) Testing with gcc 8.0.1 (Fedora 28's current version), I found that I also had to put explicit "break"s after elog(ERROR) or ereport(ERROR); apparently, for this purpose gcc doesn't recognize that those don't return. That seems like possibly a gcc bug, but it's fine because in most places we did that anyway; so this amounts to a visit from the style police. Discussion: https://postgr.es/m/15083.1525207729@sss.pgh.pa.us
* Fix interaction of foreign tuple routing with remote triggers.Robert Haas2018-05-01
| | | | | | | | | | | | | | | | | | | | | | | | Without these fixes, changes to the inserted tuple made by remote triggers are ignored when building local RETURNING tuples. In the core code, call ExecInitRoutingInfo at a later point from within ExecInitPartitionInfo so that the FDW callback gets invoked after the returning list has been built. But move CheckValidResultRel out of ExecInitRoutingInfo so that it can happen at an earlier stage. In postgres_fdw, refactor assorted deparsing functions to work with the RTE rather than the PlannerInfo, which saves us having to construct a fake PlannerInfo in cases where we don't have a real one. Then, we can pass down a constructed RTE that yields the correct deparse result when no real one exists. Unfortunately, this necessitates a hack that understands how the core code manages RT indexes for update tuple routing, which is ugly, but we don't have a better idea right now. Original report, analysis, and patch by Etsuro Fujita. Heavily refactored by me. Then worked over some more by Amit Langote. Discussion: http://postgr.es/m/5AD4882B.10002@lab.ntt.co.jp
* Remove investigative code for can't-reattach-to-shared-memory errors.Tom Lane2018-05-01
| | | | | | | | | Revert commits 23078689a, 73042b8d1, ce07aff48, f7df8043f, 6ba0cc4bd, eb16011f4, 68e7e973d, 63ca350ef. We still have a problem here, but somebody who's actually a Windows developer will need to spend time on it. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Does it help to wait before reattaching?Tom Lane2018-04-30
| | | | | | | | | | | | | | | | Revert the map/unmap dance I tried in commit 73042b8d1; that helps not at all. Instead, speculate that the unwanted allocation is being done on another thread, and thus timing variations explain the apparent unpredictability. Temporarily add a 1-second sleep before the VirtualFree call, in hopes that any such other threads will quiesce and not jog our elbow. This is obviously not a desirable long-term fix, but as a means of investigation it seems useful. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Map and unmap the shared memory block before risking VirtualFree.Tom Lane2018-04-30
| | | | | | | | | | | | | | The idea here is to get Windows' userspace infrastructure to allocate whatever space it needs for MapViewOfFileEx() before we release the locked-down space that we want to map the shared memory block into. This is a fairly brute-force attempt, and would likely (for example) fail with large shared memory on 32-bit Windows. We could perhaps ameliorate that by mapping only part of the shared memory block in this way, but for the moment I just want to see if this approach will fix dory's problem. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Further effort at preventing memory map dump from affecting the results.Tom Lane2018-04-30
| | | | | | | | Rather than elog'ing immediately, push the map data into a preallocated StringInfo. Perhaps this will prevent some of the mid-operation allocations that are evidently happening now. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Write error messages about duplicate OIDs to stderrPeter Eisentraut2018-04-30
|
* Remove "Generating" output from catalog scriptsPeter Eisentraut2018-04-30
| | | | | | So by default, they don't output anything if everything is well. Discussion: https://www.postgresql.org/message-id/867f8a1a-6cf0-d835-78d8-0844e4936241%402ndquadrant.com
* Don't do logical replication of TRUNCATE of zero tablesPeter Eisentraut2018-04-30
| | | | | | When due to publication configuration, a TRUNCATE change ends up with zero tables to be published, don't send the message out, just skip it. It's not wrong, but obviously useless overhead.
* Remove Windows module-list-dumping code.Tom Lane2018-04-30
| | | | | | | | This code is evidently allocating memory and thus confusing matters even more. Let's see whether we can learn anything with just VirtualQuery. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Dump full memory maps around failing Windows reattach code.Tom Lane2018-04-30
| | | | | | | | | | | | | | This morning's results from buildfarm member dory make it pretty clear that something is getting mapped into the just-freed space, but not what that something is. Replace my minimalistic probes with a full dump of the process address space and module space, based on Noah's work at <20170403065106.GA2624300%40tornado.leadboat.com> This is all (probably) to get reverted once we have fixed the problem, but for now we need information. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Get still more info about Windows can't-reattach-to-shared-memory errors.Tom Lane2018-04-29
| | | | | | | | | | | | After some thought about the info captured so far, it seems possible that MapViewOfFileEx is itself causing some DLL to get loaded into the space just freed by VirtualFree. The previous commit here didn't capture enough info to really prove the case for that, so let's add one more VirtualQuery in between those steps. Also, be sure to capture the post-Map state before we emit any log entries, just in case elog() is invoking some code not previously loaded. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Avoid wrong results for power() with NaN input on more platforms.Tom Lane2018-04-29
| | | | | | | | | | | | | | | Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not honored on *BSD until relatively recently, and really old platforms don't believe that NaN ^ 0 = 1 either. (This is unsurprising, perhaps, since SUSv2 doesn't require either behavior.) In hopes of getting to platform independent behavior, let's deal with all the NaN-input cases explicitly in dpow(). Note that numeric_power() doesn't know either of these special cases. But since that behavior is platform-independent, I think it should be addressed separately, and probably not back-patched. Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
* Get more info about Windows can't-reattach-to-shared-memory errors.Tom Lane2018-04-29
| | | | | | | Commit 63ca350ef neglected to probe the state of things *before* the VirtualFree call, which now looks like it might be interesting. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Avoid wrong results for power() with NaN input on some platforms.Tom Lane2018-04-29
| | | | | | | | | | | | | | | Per spec, the result of power() should be NaN if either input is NaN. It appears that on some versions of Windows, the libc function does return NaN, but it also sets errno = EDOM, confusing our code that attempts to work around shortcomings of other platforms. Hence, add guard tests to avoid substituting a wrong result for the right one. It's been like this for a long time (and the odd behavior only appears in older MSVC releases, too) so back-patch to all supported branches. Dang Minh Huong, reviewed by David Rowley Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
* In AtEOXact_Files, complain if any files remain unclosed at commit.Tom Lane2018-04-28
| | | | | | | | | | | This change makes this module act more like most of our other low-level resource management modules. It's a caller error if something is not explicitly closed by the end of a successful transaction, so issue a WARNING about it. This would not actually have caught the file leak bug fixed in commit 231bcd080, because that was in a transaction-abort path; but it still seems like a good, and pretty cheap, cross-check. Discussion: https://postgr.es/m/152056616579.4966.583293218357089052@wrigleys.postgresql.org
* Fix incorrect field type for PlannedStmt.jitFlags in outfuncs/readfuncs.Tom Lane2018-04-28
| | | | | | | This field was a bool at one point, but now it's an int. Spotted by Hari Babu; trivial patch is by Ashutosh Bapat. Discussion: https://postgr.es/m/CAJrrPGedKiFE2fqntSauUfhapCksOJzam+QtHfSgx86LhXLeOQ@mail.gmail.com
* Clarify handling of special-case values in bootstrap catalog data.Tom Lane2018-04-28
| | | | | | | | | | | | | | | I (tgl) originally coded the special case for pg_proc.pronargs as though it were a kind of default value. It seems better though to treat computable columns as an independent concern: this makes the code clearer, and probably a bit faster too since we needn't do work inside the per-column loop. Improve related comments, as well, in the expectation that there might be more cases like this in future. John Naylor, some additional comment-hacking by me Discussion: https://postgr.es/m/CAJVSVGW-D7OobzU=dybVT2JqZAx-4X1yvBJdavBmqQL05Q6CLw@mail.gmail.com
* Assorted minor doc/comment fixes.Tom Lane2018-04-28
| | | | | | | | | | | | | | | Identify pg_replication_origin as a shared catalog in catalogs.sgml, using the same boilerplate wording used for most other shared catalogs (and tweak another place where someone had randomly deviated from that boilerplate). Make an example in mmgr/README more consistent with surrounding text. Update an obsolete cross-reference in a comment in storage/block.h. Zhuo Ql Discussion: https://postgr.es/m/44296255.1819230.1524889719001@mail.yahoo.com
* Try to get some info about Windows can't-reattach-to-shared-memory errors.Tom Lane2018-04-27
| | | | | | | | | | | | Add some debug printouts focused on the idea that MapViewOfFileEx might be rounding its virtual memory allocation up more than we expect (and, in particular, more than VirtualAllocEx does). Once we've seen what this reports in one of the failures on buildfarm members dory or jacana, we might revert this ... or perhaps just decrease the log level. Discussion: https://postgr.es/m/25495.1524517820@sss.pgh.pa.us
* Adjust hints and docs to suggest CREATE EXTENSION not CREATE LANGUAGE.Tom Lane2018-04-27
| | | | | | | | | The core PLs have been extension-ified for seven years now, and we can reasonably hope that all out-of-core PLs have been too. So adjust a few places that were still recommending CREATE LANGUAGE as the user-level way to install a PL. Discussion: https://postgr.es/m/CA+TgmoaJTUDMSuSCg4k08Dv8vhbrJq9nP3ZfPbmysVz_616qxw@mail.gmail.com
* perltidy: Add option --nooutdent-long-commentsPeter Eisentraut2018-04-27
|
* perltidy: Add option --nooutdent-long-quotesPeter Eisentraut2018-04-27
|
* Remove outdated comment on how to set logtape's read buffer size.Heikki Linnakangas2018-04-27
| | | | | | | Commit b75f467b6e removed the LogicalTapeAssignReadBufferSize() function, but forgot to update this comment. The read buffer size is an argument to LogicalTapeRewindForRead() now. Doesn't seem worth going into the details in the file header comment, so remove the outdated sentence altogether.
* Post-feature-freeze pgindent run.Tom Lane2018-04-26
| | | | Discussion: https://postgr.es/m/15719.1523984266@sss.pgh.pa.us
* Preliminary work for pgindent run.Tom Lane2018-04-26
| | | | | | | Update typedefs.list from current buildfarm results. Adjust pgindent's typedef blacklist to block some more unfortunate typedef names that have snuck in since last time. Manually tweak a few places where I didn't like the initial results of pgindent'ing.
* Avoid parsing catalog data twice during BKI file construction.Tom Lane2018-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | In the wake of commit 5602265f7, we were doing duplicate-OID detection quite inefficiently, by invoking duplicate_oids which does all the same parsing of catalog headers and .dat files as genbki.pl does. That adds under half a second on modern machines, but quite a bit more on slow buildfarm critters, so it seems worth avoiding. Let's just extend genbki.pl a little so it can also detect duplicate OIDs, and remove the duplicate_oids call from the build process. (This also means that duplicate OID detection will happen during Windows builds, which AFAICS it didn't before.) This makes the use-case for duplicate_oids a bit dubious, but it's possible that people will still want to run that check without doing a whole build run, so let's keep that script. In passing, move down genbki.pl's creation of its temp output files so that it doesn't happen until after we've done parsing and validation of the input. This avoids leaving a lot of clutter around after a failure. John Naylor and Tom Lane Discussion: https://postgr.es/m/37D774E4-FE1F-437E-B3D2-593F314B7505@postgrespro.ru
* Convert unused_oids and duplicate_oids to use Catalog.pm infrastructure.Tom Lane2018-04-25
| | | | | | | | | | | | | | | | | | | unused_oids was previously a shell script, which of course didn't work at all on Windows. Also, commit 372728b0d introduced some other portability problems, as complained of by Stas Kelvich. We can improve matters by converting it to Perl. While we're at it, let's future-proof both this script and duplicate_oids to use Catalog.pm rather than having a bunch of ad-hoc logic for parsing catalog headers and .dat files. These scripts are thereby a bit slower, which doesn't seem like a problem for typical manual use. It is a little annoying for buildfarm purposes, but we should be able to fix that case by having genbki.pl make the check instead of parsing the headers twice. (That's not done in this commit, though.) Stas Kelvich, adjusted a bit by me Discussion: https://postgr.es/m/37D774E4-FE1F-437E-B3D2-593F314B7505@postgrespro.ru
* Make Catalog.pm's representation of toast and index decls more abstract.Tom Lane2018-04-25
| | | | | | | | | | Instead of immediately constructing the string we need to emit into the .BKI file, preserve the items we extracted from the header file in a hash. This eases using the info for other purposes. John Naylor (with cosmetic adjustments by me) Discussion: https://postgr.es/m/37D774E4-FE1F-437E-B3D2-593F314B7505@postgrespro.ru
* Prevent generation of bogus subquery scan paths.Robert Haas2018-04-25
| | | | | | | | | | | | | | | Commit 0927d2f46ddd4cf7d6bf2cc84b3be923e0aedc52 didn't check that consider_parallel was set for the target relation or account for the possibility that required_outer might be non-empty. To prevent future bugs of this ilk, add some assertions to add_partial_path and do a bit of future-proofing of the code recently added to recurse_set_operations. Report by Andreas Seltenreich. Patch by Jeevan Chalke. Review by Amit Kapila and by me. Discussion: http://postgr.es/m/CAM2+6=U+9otsyF2fYB8x_2TBeHTR90itarqW=qAEjN-kHaC7kw@mail.gmail.com
* Reindent Perl files with perltidy version 20170521.Tom Lane2018-04-25
| | | | 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.
* 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
* Add missing "static" marker.Tom Lane2018-04-21
| | | | Per pademelon.
* 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.
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 16:52:58 +0000