aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Remove redundant newlines from error messagesPeter Eisentraut2019-07-02
| | | | These are no longer needed/allowed with the new logging API.
* Don't treat complete_from_const as equivalent to complete_from_list.Tom Lane2019-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4f3b38fe2 supposed that complete_from_const() is equivalent to the one-element-list case of complete_from_list(), but that's not really true at all. complete_from_const() supposes that the completion is certain enough to justify wiping out whatever the user typed, while complete_from_list() will only provide completions that match the word-so-far. In practice, given the lame parsing technology used by tab-complete.c, it's fairly hard to believe that we're *ever* certain enough about a completion to justify auto-correcting user input that doesn't match. Hence, remove the inappropriate unification of the two cases. As things now stand, complete_from_const() is used only for the situation where we have no matches and we need to keep readline from applying its default complete-with-file-names behavior. This (mis?) behavior actually exists much further back, but I'm hesitant to change it in released branches. It's not too late for v12, though, especially seeing that the aforesaid commit is new in v12. Per gripe from Ken Tanzer. Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com
* Fix tab completion of "SET variable TO|=" to not offer bogus completions.Tom Lane2019-07-02
| | | | | | | | | | | | | | | | Don't think that the context "UPDATE tab SET var =" is a GUC-setting command. If we have "SET var =" but the "var" is not a known GUC variable, don't offer any completions. The most likely explanation is that we've misparsed the context and it's not really a GUC-setting command. Per gripe from Ken Tanzer. Back-patch to 9.6. The issue exists further back, but before 9.6 the code looks very different and it doesn't actually know whether the "var" name matches anything, so I desisted from trying to fix it. Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com
* Simplify psql \d's rule for ordering the indexes of a table.Tom Lane2019-07-02
| | | | | | | | | | | | | | | | | | | | The previous rule was "primary key (if any) first, then other unique indexes in name order, then all other indexes in name order". But the preference for unique indexes seems a bit obsolete since the introduction of exclusion constraints. It's no longer the case that unique indexes are the only ones that constrain what data can be in the table, and it's hard to see what other rationale there is for separating out unique indexes. Other new features like the possibility for some indexes to be INVALID (hence, not constraining anything) make this even shakier. Hence, simplify the sort order to be "primary key (if any) first, then all other indexes in name order". No documentation change, since this was never documented anyway. A couple of existing regression test cases change output, though. Discussion: https://postgr.es/m/14422.1561474929@sss.pgh.pa.us
* Remove obsolete nbtree "get root" comment.Peter Geoghegan2019-07-01
| | | | | | | | Remove a very old Berkeley era comment that doesn't seem to have anything to do with the current locking considerations within _bt_getroot(). Discussion: https://postgr.es/m/CAH2-WzmA2H+rL-xxF5o6QhMD+9x6cJTnz2Mr3Li_pbPBmqoTBQ@mail.gmail.com
* Add support for Visual Studio 2019 in build scriptsMichael Paquier2019-07-02
| | | | | | | | | | | This fixes at the same time a set of inconsistencies in the documentation and the scripts related to the versions of Windows SDK supported. Author: Haribabu Kommi Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com
* Refactor code of reindexdb for query generationMichael Paquier2019-07-02
| | | | | | | | | | | | | | This merges the portion related to REINDEX SYSTEM into the routine already available for all the other reindex types, making the query generation cleaner. While on it, change the handling of the reindex types using an enum, which allows to get rid of the hardcoded strings used directly in the query generation present for the same purpose (aka "TABLE", "DATABASE", etc.). Per discussion with Julien Rouhaud, Tom Lane, Alvaro Herrera and me. Author: Julien Rouhaud Discussion: https://postgr.es/m/CAOBaU_bSmSik_WRK9niDnm-3NkNZky6+uKxkmQwvthZvMWpS5A@mail.gmail.com
* Remove support for non-ELF BSD systemsPeter Eisentraut2019-07-01
| | | | | | This is long obsolete. Discussion: https://www.postgresql.org/message-id/8eacdc0d-123f-dbca-bacf-0a68766a4889@2ndquadrant.com
* Stamp HEAD as 13devel.Tom Lane2019-07-01
| | | | Let the hacking begin ...
* pgindent run prior to branching v12.Tom Lane2019-07-01
| | | | | pgperltidy and reformat-dat-files too, though the latter didn't find anything to change.
* Revert fix missing call to table_finish_bulk_insert during COPYDavid Rowley2019-07-02
| | | | | This reverts commits 4de60244e and b2d69806d. Further thought is required to make this work properly.
* Remove surplus call to table_finish_bulk_insertDavid Rowley2019-07-02
| | | | | | | | | | | 4de60244e added the call to table_finish_bulk_insert to the CopyMultiInsertBufferCleanup function. We use a CopyMultiInsertBuffer even for non-partitioned tables, so having the cleanup do that meant we would call table_finsh_bulk_insert twice when performing COPY FROM with a non-partitioned table. Here we can just remove the direct call in CopyFrom and let CopyMultiInsertBufferCleanup handle the call instead.
* Fix missing call to table_finish_bulk_insert during COPYDavid Rowley2019-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | 86b85044e abstracted calls to heap functions in COPY FROM to support a generic table AM. However, when performing a copy into a partitioned table, this commit neglected to call table_finish_bulk_insert for each partition. Before 86b85044e, when we always called the heap functions, there was no need to call heapam_finish_bulk_insert for partitions since it only did any work when performing a copy without WAL. For partitioned tables, this was unsupported anyway, so there was no issue. With pluggable storage, we can't make any assumptions about what the table AM might want to do in its equivalent function, so we'd better ensure we always call table_finish_bulk_insert each partition that's received a row. For now, we make the table_finish_bulk_insert call whenever we evict a CopyMultiInsertBuffer out of the CopyMultiInsertInfo. This does mean that it's possible that we call table_finish_bulk_insert multiple times per partition, which is not a problem other than being an inefficiency. Improving this requires a more invasive patch, so let's leave that for another day. In passing, move the table_finish_bulk_insert for the target of the COPY command so that it's only called when we're actually performing bulk inserts. We don't need to call this when inserting 1 row at a time. Reported-by: Robert Haas Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com
* Convert some stragglers to new frontend logging APIPeter Eisentraut2019-07-01
|
* Add missing serial commasPeter Eisentraut2019-07-01
|
* Fix many typos and inconsistenciesMichael Paquier2019-07-01
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397f44@gmail.com
* Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.Noah Misch2019-06-30
| | | | | | | | | | | UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com
* Repair logic for reordering grouping sets optimization.Andrew Gierth2019-06-30
| | | | | | | | | | | | | | The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com
* Exclude new src/test/modules/unsafe_tests directory from MSVC build.Tom Lane2019-06-30
| | | | | There's nothing to build here, and that was confusing AddContrib(). Per buildfarm.
* Blind attempt to fix SSPI-auth case in 010_dump_connstr.pl.Tom Lane2019-06-30
| | | | | | | | | | | | | | | | | Up to now, pg_regress --config-auth had a hard-wired assumption that the target cluster uses the default bootstrap superuser name. pg_dump's 010_dump_connstr.pl TAP test uses non-default superuser names, and was klugily getting around the restriction by listing the desired superuser name as a role to "create". This is pretty confusing (or at least, it confused me). Let's make it clearer by allowing --config-auth mode to be told the bootstrap superuser name. Repurpose the existing --user switch for that, since it has no other function in --config-auth mode. Per buildfarm. I don't have an environment at hand in which I can test this fix, but the buildfarm should soon show if it works. Discussion: https://postgr.es/m/3142.1561840611@sss.pgh.pa.us
* Move rolenames test out of the core regression tests.Tom Lane2019-06-30
| | | | | | | | | | | | | | | | | | | | | This test script is unsafe to run in "make installcheck" mode for (at least) two reasons: it creates and destroys some role names that don't follow the "regress_xxx" naming convention, and it sets and then resets the application_name GUC attached to every existing role. While we've not had complaints, these surely are not good things to do within a production installation, and regress.sgml pretty clearly implies that we won't do them. Rather than lose test coverage altogether, let's just move this script somewhere where it will get run by "make check" but not "make installcheck". src/test/modules/ already has that property. Since it seems likely that we'll want other regression tests in future that also exceed the constraints of "make installcheck", create a generically-named src/test/modules/unsafe_tests/ directory to hold them. Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
* Fix breakage introduced in pg_lsn_in()Peter Eisentraut2019-06-30
| | | | | Using PG_RETURN_LSN() from non-fmgr pg_lsn_in_internal() happened to work on some platforms, but should just be a plain "return".
* Don't call data type input functions in GUC check hooksPeter Eisentraut2019-06-30
| | | | | | | | | | | | | | | | | | | | Instead of calling pg_lsn_in() in check_recovery_target_lsn and timestamptz_in() in check_recovery_target_time, reorganize the respective code so that we don't raise any errors in the check hooks. The previous code tried to use PG_TRY/PG_CATCH to handle errors in a way that is not safe, so now the code contains no ereport() calls and can operate safely within the GUC error handling system. Moreover, since the interpretation of the recovery_target_time string may depend on the time zone, we cannot do the final processing of that string until all the GUC processing is done. Instead, check_recovery_target_time() now does some parsing for syntax checking, but the actual conversion to a timestamptz value is done later in the recovery code that uses it. Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/20190611061115.njjwkagvxp4qujhp%40alap3.anarazel.de
* Remove explicit error handling for obsolete date/time valuesPeter Eisentraut2019-06-30
| | | | | | | | | | The date/time values 'current', 'invalid', and 'undefined' were removed a long time ago, but the code still contains explicit error handling for the transition. To simplify the code and avoid having to handle these values everywhere, just remove the recognition of these tokens altogether now. Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Add an enforcement mechanism for global object names in regression tests.Tom Lane2019-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 18555b132 we tentatively established a rule that regression tests should use names containing "regression" for databases, and names starting with "regress_" for all other globally-visible object names, so as to circumscribe the side-effects that "make installcheck" could have on an existing installation. This commit adds a simple enforcement mechanism for that rule: if the code is compiled with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS defined, it will emit a warning (not an error) whenever a database, role, tablespace, subscription, or replication origin name is created that doesn't obey the rule. Running one or more buildfarm members with that symbol defined should be enough to catch new violations, at least in the regular regression tests. Most TAP tests wouldn't notice such warnings, but that's actually fine because TAP tests don't execute against an existing server anyway. Since it's already the case that running src/test/modules/ tests in installcheck mode is deprecated, we can use that as a home for tests that seem unsafe to run against an existing server, such as tests that might have side-effects on existing roles. Document that (though this commit doesn't in itself make it any less safe than before). Update regress.sgml to define these restrictions more clearly, and to clean up assorted lack-of-up-to-date-ness in its descriptions of the available regression tests. Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
* Fix regression tests to use only global names beginning with "regress_".Tom Lane2019-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 18555b132 we tentatively established a rule that regression tests should use names containing "regression" for databases, and names starting with "regress_" for all other globally-visible object names, so as to circumscribe the side-effects that "make installcheck" could have on an existing installation. However, no enforcement mechanism was created, so it's unsurprising that some new violations have crept in since then. In fact, a whole new *category* of violations has crept in, to wit we now also have globally-visible subscription and replication origin names, and "make installcheck" could very easily clobber user-created objects of those types. So it's past time to do something about this. This commit sanitizes the tests enough that they will pass (i.e. not generate any visible warnings) with the enforcement mechanism I'll add in the next commit. There are some TAP tests that still trigger the warnings, but the warnings do not cause test failure. Since these tests do not actually run against a pre-existing installation, there's no need to worry whether they could conflict with user-created objects. The problem with rolenames.sql testing special role names like "user" is still there, and is dealt with only very cosmetically in this patch (by hiding the warnings :-(). What we actually need to do to be safe is to take that test script out of "make installcheck" altogether, but that seems like material for a separate patch. Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
* Disallow user-created replication origins named "pg_xxx".Tom Lane2019-06-29
| | | | | | | | | Since we generate such names internally, it seems like a good idea to have a policy of disallowing them for user use, as we do for many other object types. Otherwise attempts to use them will randomly fail due to collisions with internally-generated names. Discussion: https://postgr.es/m/3606.1561747369@sss.pgh.pa.us
* Remove unnecessary header from be-secure-gssapi.cMichael Paquier2019-06-29
| | | | | | | | | libpq/libpq-be.h is included by libpq/libpq.h so there is no need to explicitly include it separately. Author: Daniel Gustafsson Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se
* Fix for dropped columns in a partitioned table's default partitionAlvaro Herrera2019-06-28
| | | | | | | | | | | | | | | | | | We forgot to map column numbers to/from the default partition for various operations, leading to valid cases failing with spurious errors, such as ERROR: attribute N of type some_partition has been dropped It was also possible that the search for conflicting rows in the default partition when attaching another partition would fail to detect some. Secondarily, it was also possible that such a search should be skipped (because the constraint was implied) but wasn't. Fix all this by mapping column numbers when necessary. Reported by: Daniel Wilches Author: Amit Langote Discussion: https://postgr.es/m/15873-8c61945d6b3ef87c@postgresql.org
* Fix misleading comment in nodeIndexonlyscan.c.Thomas Munro2019-06-28
| | | | | | | | | | | The stated reason for acquiring predicate locks on heap pages hasn't existed since commit c01262a8, so fix the comment. Perhaps in a later release we'll also be able to change the code to use tuple locks. Back-patch all the way. Reviewed-by: Ashwin Agrawal Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com
* Update reference to sampling algorithm in analyze.cTomas Vondra2019-06-27
| | | | | | | | | | Commit 83e176ec1 moved row sampling functions from analyze.c to utils/misc/sampling.c, but failed to update comment referring to the sampling algorithm from Jeff Vitter's paper. Correct the comment by pointing to utils/misc/sampling.c. Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com
* Fix use-after-free introduced in 55ed3defc966Alvaro Herrera2019-06-27
| | | | | | | | Evidenced by failure under RELCACHE_FORCE_RELEASE (buildfarm member prion). Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqGV=k_Eh4jBiQw66ivvdG+EUkrEYeHTYL1SvDj_YOYV0g@mail.gmail.com
* Update commentPeter Eisentraut2019-06-27
| | | | | | Function was renamed/replaced in c2fe139c201c48f1133e9fbea2dd99b8efe2fadd but the header comment was not updated.
* Remove remaining traces of Rand_OpenSSL() from the treeMichael Paquier2019-06-27
| | | | | | | | | fe0a0b5 has removed the last use of this routine from pgcrypto, leading to a useless symbol definition and an extra configure check. Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/20190626142544.GN1714@paquier.xyz
* Fix partitioned index creation with foreign partitionsAlvaro Herrera2019-06-26
| | | | | | | | | | | | | | | | | | | | | When a partitioned tables contains foreign tables as partitions, it is not possible to implement unique or primary key indexes -- but when regular indexes are created, there is no reason to do anything other than ignoring such partitions. We were raising errors upon encountering the foreign partitions, which is unfriendly and doesn't protect against any actual problems. Relax this restriction so that index creation is allowed on partitioned tables containing foreign partitions, becoming a no-op on them. (We may later want to redefine this so that the FDW is told to create the indexes on the foreign side.) This applies to CREATE INDEX, as well as ALTER TABLE / ATTACH PARTITION and CREATE TABLE / PARTITION OF. Backpatch to 11, where indexes on partitioned tables were introduced. Discussion: https://postgr.es/m/15724-d5a58fa9472eef4f@postgresql.org Author: Álvaro Herrera Reviewed-by: Amit Langote
* Follow the rule that regression-test-created roles are named "regress_xxx".Tom Lane2019-06-25
| | | | | Commit 1c5d9270e had not gotten the word about this. (For previous context, see 18555b132.)
* Add support for OpenSSL 1.1.0 and newer versions in MSVC scriptsMichael Paquier2019-06-26
| | | | | | | | | | | | | | | | | | | | | Up to now, the MSVC build scripts are able to support only one fixed version of OpenSSL, and they lacked logic to detect the version of OpenSSL a given compilation of Postgres is linking to (currently 1.0.2, the latest LTS of upstream which will be EOL'd at the end of 2019). This commit adds more logic to detect the version of OpenSSL used by a build and makes use of it to add support for compilation with OpenSSL 1.1.0 which requires a new set of compilation flags to work properly. The supported OpenSSL installers have changed their library layer with various library renames with the upgrade to 1.1.0, making the logic a bit more complicated. The scripts are now able to adapt to the new world order. Reported-by: Sergey Pashkov Author: Juan José Santamaría Flecha, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org
* Add toast-level reloption for vacuum_index_cleanupMichael Paquier2019-06-25
| | | | | | | | | | | | | | a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
* Remove misleading comment from pathnodes.h.Thomas Munro2019-06-25
| | | | | | | | | | As of commit e5253fdc, it is no longer true that the leader always executes the subplan of a Gather Merge node. Remove comment to that effect. Back-patch to 11. Discussion: https://postgr.es/m/CA%2BhUKGJEaZJYezXAOutuiWT%2BfxCA44%2BoKtVPAND2ubLiigR%3D-w%40mail.gmail.com
* Purely-cosmetic adjustments in tablecmds.c.Tom Lane2019-06-24
| | | | | | | | | | | | | | | | Move ATExecAlterColumnGenericOptions away from where it was unthinkingly dropped, in the middle of a lot of ALTER COLUMN TYPE code. I don't have any high principles about where to put it instead, so let's just put it after ALTER COLUMN TYPE and before ALTER OWNER, matching existing decisions about how to order related code stanzas. Also add the minimal function header comment that the original author was too cool to bother with. Along the way, upgrade header comments for nearby ALTER COLUMN TYPE functions. Discussion: https://postgr.es/m/14787.1561403130@sss.pgh.pa.us
* Update unicode_norm_table.h to Unicode 12.1.0Peter Eisentraut2019-06-24
|
* Make script output more pgindent compatiblePeter Eisentraut2019-06-24
|
* Correct script name in README filePeter Eisentraut2019-06-24
|
* Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.Tom Lane2019-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reverts all the code changes of commit e76de8861, which turns out to have been seriously misguided. We can't wait till later to compute the definition string for an index; we must capture that before applying the data type change for any column it depends on, else ruleutils.c will deliverr wrong/misleading results. (This fine point was documented nowhere, of course.) I'd also managed to forget that ATExecAlterColumnType executes once per ALTER COLUMN TYPE clause, not once per statement; which resulted in the code being basically completely broken for any case in which multiple ALTER COLUMN TYPE clauses are applied to a table having non-constraint indexes that must be rebuilt. Through very bad luck, none of the existing test cases nor the ones added by e76de8861 caught that, but of course it was soon found in the field. The previous patch also had an implicit assumption that if a constraint's index had a dependency on a table column, so would the constraint --- but that isn't actually true, so it didn't fix such cases. Instead of trying to delete unneeded index dependencies later, do the is-there-a-constraint lookup immediately on seeing an index dependency, and switch to remembering the constraint if so. In the unusual case of multiple column dependencies for a constraint index, this will result in duplicate constraint lookups, but that's not that horrible compared to all the other work that happens here. Besides, such cases did not work at all before, so it's hard to argue that they're performance-critical for anyone. Per bug #15865 from Keith Fiske. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org
* Drop test user when done with it.Tom Lane2019-06-24
| | | | | | Commit d7f8d26d9 added a test case that created a user, but forgot to drop it again. This is no good; for one thing, it causes repeated "make installcheck" runs to fail.
* Upgrade internal error message to externalPeter Eisentraut2019-06-24
| | | | | | As part of REINDEX CONCURRENTLY, this formerly internal-only error message becomes potentially user-visible (see regression tests), so change from errmsg_internal() to errmsg(), and update comment.
* Don't call PG_RETURN_BOOL() in a function not returning Datum.Noah Misch2019-06-23
| | | | This code is new in v12, and the defect probably was not user-visible.
* Add security checks to the multivariate MCV estimation code.Dean Rasheed2019-06-23
| | | | | | | | | | | | | | | | | | | The multivariate MCV estimation code may run user-defined operators on the values in the MCV list, which means that those operators may potentially leak the values from the MCV list. Guard against leaking data to unprivileged users by checking that the user has SELECT privileges on the table or all of the columns referred to by the statistics. Additionally, if there are any securityQuals on the RTE (either due to RLS policies on the table, or accessing the table via a security barrier view), not all rows may be visible to the current user, even if they have table or column privileges. Thus we further insist that the operator be leakproof in this case. Dean Rasheed, reviewed by Tomas Vondra. Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com
* Remove unnecessary comment.Thomas Munro2019-06-23
| | | | | Author: Vik Fearing Discussion: https://postgr.es/m/150d3e9f-c7ec-3fb3-4fdb-def47c4144af%402ndquadrant.com
* Fix spinlock assembly code for MIPS so it works on MIPS r6.Tom Lane2019-06-22
| | | | | | | | | | | | | | | | | | | | | | | | Original MIPS-I processors didn't have the LL/SC instructions (nor any other userland synchronization primitive). If the build toolchain targets that ISA variant by default, as an astonishingly large fraction of MIPS platforms still do, the assembler won't take LL/SC without coercion in the form of a ".set mips2" instruction. But we issued that unconditionally, making it an ISA downgrade for chips later than MIPS2. That breaks things for the latest MIPS r6 ISA, which encodes these instructions differently. Adjust the code so we don't change ISA level if it's >= 2. Note that this patch doesn't change what happens on an actual MIPS-I processor: either the kernel will emulate these instructions transparently, or you'll get a SIGILL failure. That tradeoff seemed fine in 2002 when this code was added (cf 3cbe6b247), and it's even more so today when MIPS-I is basically extinct. But let's add a comment about that. YunQiang Su (with cosmetic adjustments by me). Back-patch to all supported branches. Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-24 19:32:00 +0000