aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers.Tom Lane2016-11-08
| | | | | | | | | | | | | | | The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
* Improve handling of dead tuples in hash indexes.Robert Haas2016-11-08
| | | | | | | | | | | When squeezing a bucket during vacuum, it's not necessary to retain any tuples already marked as dead, so ignore them when deciding which tuples must be moved in order to empty a bucket page. Similarly, when splitting a bucket, relocating dead tuples to the new bucket is a waste of effort; instead, just ignore them. Amit Kapila, reviewed by me. Testing help provided by Ashutosh Sharma.
* Change qr/foo$/m to qr/foo\n/m, for Perl 5.8.8.Noah Misch2016-11-07
| | | | | | | | | | | | | | | | | | In each case, absence of a trailing newline would itself constitute a PostgreSQL bug. Therefore, this slightly enhances the changed tests. This works around a bug that last appeared in Perl 5.8.8, fixing src/test/modules/test_pg_dump when run against that version. Commit e7293e3271bf618eeb2d4779a15fc516a69fe463 worked around the bug, but the subsequent addition of test_pg_dump introduced affected code. As that commit had shown, slight increases in pattern complexity can suppress the bug. This commit edits qr/foo$/m patterns too complex to encounter the bug today, for style consistency and robustness against unrelated pattern changes. Back-patch to 9.6, where test_pg_dump was introduced. As of this writing, a fresh MSYS installation includes an affected Perl 5.8.8. The Perl 5.8.8 in Red Hat Enterprise Linux 5.11 carries a patch that renders it unaffected, but the Perl 5.8.5 of Red Hat Enterprise Linux 4.4 is affected.
* Band-aid fix for incorrect use of view options as StdRdOptions.Tom Lane2016-11-07
| | | | | | | | | | We really ought to make StdRdOptions and the other decoded forms of reloptions self-identifying, but for the moment, assume that only plain relations could possibly be user_catalog_tables. Fixes problem with bogus "ON CONFLICT is not supported on table ... used as a catalog table" error when target is a view with cascade option. Discussion: <26681.1477940227@sss.pgh.pa.us>
* Revert "Provide DLLEXPORT markers for C functions via PG_FUNCTION_INFO_V1 ↵Tom Lane2016-11-07
| | | | | | | | | | macro." This reverts commit c8ead2a3974d3eada145a0e18940150039493cc9. Seems there is no way to do this that doesn't cause MSVC to give warnings, so let's just go back to the way we've been doing it. Discussion: <11843.1478358206@sss.pgh.pa.us>
* pg_upgrade: Add NLSPeter Eisentraut2016-11-07
| | | | Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* pg_rewing pg_upgrade: Fix translation markersPeter Eisentraut2016-11-07
| | | | | In pg_log_v(), we need to translate the fmt before processing, not the formatted message afterwards.
* Save redundant code for pseudotype I/O functionsPeter Eisentraut2016-11-07
| | | | | | Use a macro to generate the in and out functions for pseudotypes that reject all input and output, saving many lines of redundant code. Parameterize the error messages to reduce translatable strings.
* Sync pltcl_build_tuple_result's error handling with pltcl_trigger_handler.Tom Lane2016-11-06
| | | | Meant to do this in 26abb50c4, but forgot.
* Support PL/Tcl functions that return composite types and/or sets.Tom Lane2016-11-06
| | | | | | Jim Nasby, rather heavily editorialized by me Patch: <f2134651-14b3-efeb-f274-c69f3c084031@BlueTreble.com>
* Modernize result-tuple construction in pltcl_trigger_handler().Tom Lane2016-11-06
| | | | | | | | | | | | | | | | Use Tcl_ListObjGetElements instead of Tcl_SplitList. Aside from being possibly more efficient in its own right, this means we are no longer responsible for freeing a malloc'd result array, so we can get rid of a PG_TRY/PG_CATCH block. Use heap_form_tuple instead of SPI_modifytuple. We don't need the extra generality of the latter, since we're always replacing all columns. Nor do we need its memory-context-munging, since at this point we're already out of the SPI environment. Per comparison of this code to tuple-building code submitted by Jim Nasby. I've abandoned the thought of merging the two cases into a single routine, but we may as well make the older code simpler and faster where we can.
* Rationalize and document pltcl's handling of magic ".tupno" array element.Tom Lane2016-11-06
| | | | | | | | | | | | | | | | | | | | | | For a very long time, pltcl's spi_exec and spi_execp commands have had a behavior of storing the current row number as an element of output arrays, but this was never documented. Fix that. For an equally long time, pltcl_trigger_handler had a behavior of silently ignoring ".tupno" as an output column name, evidently so that the result of spi_exec could be used directly as a trigger result tuple. Not sure how useful that really is, but in any case it's bad that it would break attempts to use ".tupno" as an actual column name. We can fix it by not checking for ".tupno" until after we check for a column name match. This comports with the effective behavior of spi_exec[p] that ".tupno" is only magic when you don't have an actual column named that. In passing, wordsmith the description of returning modified tuples from a pltcl trigger. Noted while working on Jim Nasby's patch to support composite results from pltcl. The inability to return trigger tuples using ".tupno" as a column name is a bug, so back-patch to all supported branches.
* Need to do SPI_push/SPI_pop around expression evaluation in plpgsql.Tom Lane2016-11-06
| | | | | | | | | | | | | | | We must do this in case the expression evaluation results in calling another plpgsql function (or, really, anything using SPI). I missed the need for this when I converted exec_cast_value() from doing a simple InputFunctionCall() to doing ExecEvalExpr() in commit 1345cc67b. There is a SPI_push_conditional in InputFunctionCall(), so that there was no bug before that. Per bug #14414 from Marcos Castedo. Add a regression test based on his example, which was that a plpgsql function in a domain check constraint didn't work when assigning to a domain-type variable within plpgsql. Report: <20161106010947.1387.66380@wrigleys.postgresql.org>
* Fix silly nil-pointer-dereference bug introduced in commit d5f6f13f8.Tom Lane2016-11-06
| | | | | | | Don't fetch record->xl_info before we've verified that record isn't NULL. Per Coverity. Michael Paquier
* More zic cleanup.Tom Lane2016-11-06
| | | | | | | | | | | | | | | | The workaround the IANA guys chose to get rid of the clang warning we'd silenced in commit 23ed2ba81 turns out not to satisfy Coverity. Go back to the previous solution, ie, remove the useless comparison to SIZE_MAX. (In principle, there could be machines out there where it's not useless because ptrdiff_t is wider than size_t. But the whole thing is pretty academic anyway, as we could never approach this limit for any sane estimate of the amount of data that zic will ever be asked to work with.) Also, s/lineno/lineno_t/g, because if we accept their decision to start using "lineno" as a typedef, it is going to have very unpleasant consequences in our next pgindent run. Noted that while fooling with pltcl yesterday.
* Improve minor error-handling details in pltcl.Tom Lane2016-11-05
| | | | | | | | | | | | | | | | Don't ask Tcl_GetIndexFromObj to store an error message in the interpreter in cases where the next argument isn't necessarily one of the options we're asking it to check for. At best that is a waste of time, and at worst it might cause an inappropriate error result to get left behind. Be sure to check for valid syntax (ie, no command arguments) in pltcl_SPI_lastoid. Extracted from a larger and otherwise-unrelated patch. Jim Nasby Patch: <f2134651-14b3-efeb-f274-c69f3c084031@BlueTreble.com>
* Adjust cost_merge_append() to reflect use of binaryheap_replace_first().Tom Lane2016-11-05
| | | | | | | | | | | | | | | Commit 7a2fe9bd0 improved merge append so that replacement of a tuple takes log(N) operations, not twice log(N). Since cost_merge_append knew about that explicitly, we should adjust it. This probably makes little difference in practice, but the obsolete comment is confusing. Ideally this would have been put in in 9.3 with the underlying behavior change; but I'm not going to back-patch it, since there's some small chance of changing a plan choice that somebody's optimized for. Thomas Munro Discussion: <CAEepm=0WQBSvuYcMOUj4Ga4NXpu2J=ejZcE=e=eiTjTX-6_gDw@mail.gmail.com>
* Remove duplicate macro definition.Tom Lane2016-11-05
| | | | | | | Seems to be a copy-and-pasteo. Odd that we heard no reports of compiler warnings about it. Thomas Munro
* pgwin32_is_junction's argument should be "const char *" not "char *".Tom Lane2016-11-05
| | | | | | We're passing const strings to it in places, and that's not an unreasonable thing to do. Per buildfarm (noted on frogmouth in particular).
* Provide DLLEXPORT markers for C functions via PG_FUNCTION_INFO_V1 macro.Tom Lane2016-11-04
| | | | | | | | | | | | Second try at the change originally made in commit 8518583cd; this time with contrib updates so that manual extern declarations are also marked with PGDLLEXPORT. The release notes should point this out as a significant source-code change for extension authors, since they'll have to make similar additions to avoid trouble on Windows. Laurenz Albe, doc change by me Patch: <A737B7A37273E048B164557ADEF4A58B53962ED8@ntex2010a.host.magwien.gv.at>
* Be more consistent about masking xl_info with ~XLR_INFO_MASK.Tom Lane2016-11-04
| | | | | | | | | | | | Generally, WAL resource managers are only supposed to examine the top 4 bits of a WAL record's xl_info; the rest are reserved for the WAL mechanism itself. A few places were not consistent about doing this with respect to XLOG_CHECKPOINT and XLOG_SWITCH records. There's no bug currently, since no additional bits ever get set in these specific record types, but that might not be true forever. Let's follow the generic coding rule here too. Michael Paquier
* Improve tab completion for CREATE TRIGGER.Kevin Grittner2016-11-04
| | | | This includes support for the new REFERENCING clause.
* Implement syntax for transition tables in AFTER triggers.Kevin Grittner2016-11-04
| | | | | | | | | | | | This is infrastructure for the complete SQL standard feature. No support is included at this point for execution nodes or PLs. The intent is to add that soon. As this patch leaves things, standard syntax can create tuplestores to contain old and/or new versions of rows affected by a statement. References to these tuplestores are in the TriggerData structure. C triggers can access the tuplestores directly, so they are usable, but they cannot yet be referenced within a SQL statement.
* pg_xlogdump: Add NLSPeter Eisentraut2016-11-04
| | | | Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* pg_test_timing: Add NLSPeter Eisentraut2016-11-04
| | | | | | Also straighten out use of time unit abbreviations a bit. Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* pg_test_fsync: Add NLSPeter Eisentraut2016-11-04
| | | | Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* pg_archivecleanup: Add NLSPeter Eisentraut2016-11-04
| | | | Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
* Add API to check if an existing exclusive lock allows cleanup.Robert Haas2016-11-04
| | | | | | | | | | | | | | | | | | | | | | LockBufferForCleanup() acquires a cleanup lock unconditionally, and ConditionalLockBufferForCleanup() acquires a cleanup lock if it is possible to do so without waiting; this patch adds a new API, IsBufferCleanupOK(), which tests whether an exclusive lock already held happens to be a cleanup lock. This is possible because a cleanup lock simply means an exclusive lock plus the assurance any other pins on the buffer are newer than our own pin. Therefore, just as the existing functions decide that the exclusive lock that they've just taken is a cleanup lock if they observe the pin count to be 1, this new function allows us to observe that the pin count is 1 on a buffer we've already locked. This is useful in situations where a backend definitely wishes to modify the buffer and also wishes to perform cleanup operations if possible. The patch to eliminate heavyweight locking by hash indexes uses this, and it may have other applications as well. Amit Kapila, per a suggestion from me. Some comment adjustments by me as well.
* Sync our copy of the timezone library with IANA tzcode master.Tom Lane2016-11-03
| | | | | | | | | | | | | | | | | | | | | | This patch absorbs some unreleased fixes for symlink manipulation bugs introduced in tzcode 2016g. Ordinarily I'd wait around for a released version, but in this case it seems like we could do with extra testing, in particular checking whether it works in EDB's VMware build environment. This corresponds to commit aec59156abbf8472ba201b6c7ca2592f9c10e077 in https://github.com/eggert/tz. Per a report from Sandeep Thakkar, building in an environment where hard links are not supported in the timezone data installation directory failed, because upstream code refactoring had broken the case of symlinking from an existing symlink. Further experimentation also showed that the symlinks were sometimes made incorrectly, with too many or too few "../"'s in the symlink contents. This should get back-patched, but first let's see what the buildfarm makes of it. I'm not too sure about the new dependency on linkat(2). Report: <CANFyU94_p6mqRQc2i26PFp5QAOQGB++AjGX=FO8LDpXw0GSTjw@mail.gmail.com> Discussion: http://mm.icann.org/pipermail/tz/2016-November/024431.html
* psql: Split up "Modifiers" column in \d and \dDPeter Eisentraut2016-11-03
| | | | | | Make separate columns "Collation", "Nullable", "Default". Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
* psql: Tab-complete LOCK [TABLE] ... IN {ACCESS|ROW|SHARE}.Robert Haas2016-11-03
| | | | | | Suggest the lock modes that begin with the word in question. Thomas Munro, reviewed by Marllius Ribeiro. Comments tweaked by me.
* libpq: Allow connection strings and URIs to specify multiple hosts.Robert Haas2016-11-03
| | | | | | | | | | It's also possible to specify a separate port for each host. Previously, we'd loop over every address returned by looking up the host name; now, we'll try every address for every host name. Patch by me. Victor Wagner wrote an earlier patch for this feature, which I read, but I didn't use any of his code. Review by Mithun Cy.
* Don't make FK-based selectivity estimates in inheritance situations.Tom Lane2016-11-02
| | | | | | | | | | | | | | | | | | | The foreign-key-aware logic for estimation of join sizes (added in commit 100340e2d) blindly tried to apply the concept to rels that are actually parents of inheritance trees. This is just plain wrong so far as the referenced relation is concerned, since the inheritance scan may well produce lots of rows that are not participating in the constraint. It's wrong for the referencing relation too, for the same reason; although on that end we could conceivably detect whether all members of the inheritance tree have equivalent FK constraints pointing to the same referenced rel, and then proceed more or less as we do now. But pending somebody writing code to do that, we must disable this, because it's producing completely silly estimates when there's an FK linking the heads of inheritance trees. Per bug #14404 from Clinton Adams. Back-patch to 9.6 where the new estimation logic came in. Report: <20161028200412.15987.96482@wrigleys.postgresql.org>
* Don't convert Consts into Vars during setrefs.c processing.Tom Lane2016-11-02
| | | | | | | | | | | | | | | | | | | | | | | | | While converting expressions in an upper-level plan node so that they reference Vars and expressions provided by the input plan node(s), don't convert plain Const items, even if there happens to be a matching Const in the input. It's silly to do so because a Var is more expensive to execute than a Const. Moreover, converting can fool ExecCheckPlanOutput's check that an insert or update query inserts nulls into dropped columns, leading to "query provides a value for a dropped column" errors during INSERT or UPDATE on a table with a dropped column. We could solve this by making that check more complicated, but I don't see the point; this fix should save a marginal number of cycles, and it also makes for less messy EXPLAIN output, as shown by the ensuing regression test result changes. Per report from Pavel Hanák. I have not incorporated a test case based on that example, as there doesn't seem to be a simple way of checking this in isolation without making a bunch of assumptions about other planner and SQL-function behavior. Back-patch to 9.6. This setrefs.c behavior exists much further back, but there is not currently reason to think that it causes problems before 9.6. Discussion: <83shraampf.fsf@is-it.eu>
* Add make rules to download raw Unicode mapping filesPeter Eisentraut2016-11-01
| | | | | | This serves as implicit documentation and is handy if someone wants to tweak things. The rules are not part of a normal build, like this entire directory.
* Remove declarations for pq_putmessage_hook and pq_flush_hook.Robert Haas2016-10-31
| | | | | | | | Commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d added these in error. They were part of an earlier design for that patch and survived in the committed version only by inadvertency. Julien Rouhaud
* Fix nasty performance problem in tsquery_rewrite().Tom Lane2016-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | tsquery_rewrite() tries to find matches to subsets of AND/OR conditions; for example, in the query 'a | b | c' the substitution subquery 'a | c' should match and lead to replacement of the first and third items. That's fine, but the matching algorithm apparently takes about O(2^N) for an N-clause query (I say "apparently" because the code is also both unintelligible and uncommented). We could probably do better than that even without any extra assumptions --- but actually, we know that the subclauses are sorted, indeed are depending on that elsewhere in this very same function. So we can just scan the two lists a single time to detect matches, as though we were doing a merge join. Also do a re-flattening call (QTNTernary()) in tsquery_rewrite_query, just to make sure that the tree fits the expectations of the next search cycle. I didn't try to devise a test case for this, but I'm pretty sure that the oversight could have led to failure to match in some cases where a match would be expected. Improve comments, and also stick a CHECK_FOR_INTERRUPTS into dofindsubquery, just in case it's still too slow for somebody. Per report from Andreas Seltenreich. Back-patch to all supported branches. Discussion: <8760oasf2y.fsf@credativ.de>
* Fix bogus tree-flattening logic in QTNTernary().Tom Lane2016-10-30
| | | | | | | | | | | | | | QTNTernary() contains logic to flatten, eg, '(a & b) & c' into 'a & b & c', which is all well and good, but it tries to do that to NOT nodes as well, so that '!!a' gets changed to '!a'. Explicitly restrict the conversion to be done only on AND and OR nodes, and add a test case illustrating the bug. In passing, provide some comments for the sadly naked functions in tsquery_util.c, and simplify some baroque logic in QTNFree(), which I think may have been leaking some items it intended to free. Noted while investigating a complaint from Andreas Seltenreich. Back-patch to all supported versions.
* Improve speed of aggregates that use array_append as transition function.Tom Lane2016-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the previous coding, if an aggregate's transition function returned an expanded array, nodeAgg.c and nodeWindowAgg.c would always copy it and thus force it into the flat representation. This led to ping-ponging between flat and expanded formats, which costs a lot. For an aggregate using array_append as transition function, I measured about a 15X slowdown compared to the pre-9.5 code, when working on simple int[] arrays. Of course, the old code was already O(N^2) in this usage due to copying flat arrays all the time, but it wasn't quite this inefficient. To fix, teach nodeAgg.c and nodeWindowAgg.c to allow expanded transition values without copying, so long as the transition function takes care to return the transition value already properly parented under the aggcontext. That puts a bit of extra responsibility on the transition function, but doing it this way allows us to not need any extra logic in the fast path of advance_transition_function (ie, with a pass-by-value transition value, or with a modified-in-place pass-by-reference value). We already know that that's a hot spot so I'm loath to add any cycles at all there. Also, while only array_append currently knows how to follow this convention, this solution allows other transition functions to opt-in without needing to have a whitelist in the core aggregation code. (The reason we would need a whitelist is that currently, if you pass a R/W expanded-object pointer to an arbitrary function, it's allowed to do anything with it including deleting it; that breaks the core agg code's assumption that it should free discarded values. Returning a value under aggcontext is the transition function's signal that it knows it is an aggregate transition function and will play nice. Possibly the API rules for expanded objects should be refined, but that would not be a back-patchable change.) With this fix, an aggregate using array_append is no longer O(N^2), so it's much faster than pre-9.5 code rather than much slower. It's still a bit slower than the bespoke infrastructure for array_agg, but the differential seems to be only about 10%-20% rather than orders of magnitude. Discussion: <6315.1477677885@sss.pgh.pa.us>
* Fix memory leak in tar file paddingMagnus Hagander2016-10-30
| | | | Spotted by Coverity, patch by Michael Paquier
* Fix leftover reference to background writer performing checkpoints.Robert Haas2016-10-28
| | | | | This was changed in PostgreSQL 9.2, but somehow this comment never got updated.
* Remove invitation to report a bug about unknown encodingPeter Eisentraut2016-10-27
| | | | | | | | The error message when we couldn't determine the encoding from a locale said to report a bug about that. That might have been appropriate when this code was first added, but by now this works pretty solidly and any encodings we don't recognize we probably just don't support. We still print the warning, but no longer invite the bug report.
* Add function name to PyArg_ParseTuple()Peter Eisentraut2016-10-27
| | | | | | This causes the supplied function name to appear in any error message, making the error message friendlier and relieving us from having to provide our own in some cases.
* Format PL/Python module contents test verticallyPeter Eisentraut2016-10-27
| | | | It makes it readable again and makes merges more manageable.
* If the stats collector dies during Hot Standby, restart it.Robert Haas2016-10-27
| | | | | | | | This bug exists as far back as 9.0, when Hot Standby was introduced, so back-patch to all supported branches. Report and patch by Takayuki Tsunakawa, reviewed by Michael Paquier and Kuntal Ghosh.
* Fix possible pg_basebackup failure on standby with "include WAL".Robert Haas2016-10-27
| | | | | | | | | | | | | | | If a restartpoint flushed no dirty buffers, it could fail to update the minimum recovery point, leading to a minimum recovery point prior to the starting REDO location. perform_base_backup() would interpret that as meaning that no WAL files at all needed to be included in the backup, failing an internal sanity check. To fix, have restartpoints always update the minimum recovery point to just after the checkpoint record itself, so that the file (or files) containing the checkpoint record will always be included in the backup. Code by Amit Kapila, per a design suggestion by me, with some additional work on the code comment by me. Test case by Michael Paquier. Report by Kyotaro Horiguchi.
* Avoid using a C++ keyword in header filePeter Eisentraut2016-10-26
| | | | per cpluspluscheck
* Properly indent postgresql.conf comments to alignBruce Momjian2016-10-26
| | | | A few comments were misaligned.
* Fix incorrect trigger-property updating in ALTER CONSTRAINT.Tom Lane2016-10-26
| | | | | | | | | | | | | | | | The code to change the deferrability properties of a foreign-key constraint updated all the associated triggers to match; but a moment's examination of the code that creates those triggers in the first place shows that only some of them should track the constraint's deferrability properties. This leads to odd failures in subsequent exercise of the foreign key, as the triggers are fired at the wrong times. Fix that, and add a regression test comparing the trigger properties produced by ALTER CONSTRAINT with those you get by creating the constraint as-intended to begin with. Per report from James Parks. Back-patch to 9.4 where this ALTER functionality was introduced. Report: <CAJ3Xv+jzJ8iNNUcp4RKW8b6Qp1xVAxHwSXVpjBNygjKxcVuE9w@mail.gmail.com>
* Fix not-HAVE_SYMLINK code in zic.c.Tom Lane2016-10-26
| | | | | | | | | | | I broke this in commit f3094920a. Apparently it's dead code anyway, at least as far as our buildfarm is concerned (and the upstream IANA code doesn't worry at all about symlink() not being present). But as long as the rest of our code is willing to guard against not having symlink(), this should too. Noted while investigating a tangentially-related complaint from Sandeep Thakkar. Back-patch to keep branches in sync.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 19:27:38 +0000