- 14 Feb, 2020 1 commit
-
-
Michael Paquier authored
Since its introduction in fe59e566, the code in charge of validating and converting a file path includes some extra handling for absolute paths pointing to an external log_directory, but this has never been used. Author: Antonin Houska Reviewed-by: Julien Rouhaud, Michael Paquier Discussion: https://postgr.es/m/32663.1581592539@antos
-
- 13 Feb, 2020 3 commits
-
-
Tom Lane authored
This allows these modules to be installed into a database without superuser privileges (assuming that the DBA or sysadmin has installed the module's files in the expected place). You only need CREATE privilege on the current database, which by default would be available to the database owner. The following modules are marked trusted: btree_gin btree_gist citext cube dict_int earthdistance fuzzystrmatch hstore hstore_plperl intarray isn jsonb_plperl lo ltree pg_trgm pgcrypto seg tablefunc tcn tsm_system_rows tsm_system_time unaccent uuid-ossp In the future we might mark some more modules trusted, but there seems to be no debate about these, and on the whole it seems wise to be conservative with use of this feature to start out with. Discussion: https://postgr.es/m/32315.1580326876@sss.pgh.pa.us
-
Jeff Davis authored
The write buffer was already lazily-allocated, so this is more symmetric. It also means that a freshly-rewound tape (whether for reading or writing) is not consuming memory for the buffer. Discussion: https://postgr.es/m/97c46a59c27f3c38e486ca170fcbc618d97ab049.camel%40j-davis.com
-
Tom Lane authored
Commit 6bf0bc84 replaced float.c's CHECKFLOATVAL() macro with static inline subroutines, but that wasn't too well thought out. In the original coding, the unlikely condition (isinf(result) or result == 0) was checked first, and the inf_is_valid or zero_is_valid condition only afterwards. The inline-subroutine coding caused that to be swapped around, which is pretty horrid for performance because (a) in common cases the is_valid condition is twice as expensive to evaluate (e.g., requiring two isinf() calls not one) and (b) in common cases the is_valid condition is false, requiring us to perform the unlikely-condition check anyway. Net result is that one isinf() call becomes two or three, resulting in visible performance loss as reported by Keisuke Kuroda. The original fix proposal was to revert the replacement of the macro, but on second thought, that macro was just a bad idea from the beginning: if anything it's a net negative for readability of the code. So instead, let's just open-code all the overflow/underflow tests, being careful to test the unlikely condition first (and mark it unlikely() to help the compiler get the point). Also, rather than having N copies of the actual ereport() calls, collapse those into out-of-line error subroutines to save some code space. This does mean that the error file/line numbers won't be very helpful for figuring out where the issue really is --- but we'd already burned that bridge by putting the ereports into static inlines. In HEAD, check_float[48]_val() are gone altogether. In v12, leave them present in float.h but unused in the core code, just in case some extension is depending on them. Emre Hasegeli, with some kibitzing from me and Andres Freund Discussion: https://postgr.es/m/CANDwggLe1Gc1OrRqvPfGE=kM9K0FSfia0hbeFCEmwabhLz95AA@mail.gmail.com
-
- 12 Feb, 2020 7 commits
-
-
Peter Geoghegan authored
Use a top-level "variablelist", with one item per B-Tree support function. This structure matches the structure used by various "Extensibility" sections in other documentation chapters for other index access methods. An explicit list makes it much clearer where each item begins and ends. This wasn't really a problem before now, but an upcoming patch that adds deduplication to nbtree will need to have its own new B-Tree support function. Ease the burden of translators by tidying up btree.sgml ahead of committing the deduplication patch.
-
Tom Lane authored
The GRANTED BY clause in GRANT/REVOKE ROLE has been there since 2005 but was never documented. I'm not sure now whether that was just an oversight or was intentional (given the limited capability of the option). But seeing that pg_dumpall does emit code that uses this option, it seems like not documenting it at all is a bad idea. Also, when we upgraded the syntax to allow CURRENT_USER/SESSION_USER as the privilege recipient, the role form of GRANT was incorrectly not modified to show that, and REVOKE's docs weren't touched at all. Although I'm not that excited about GRANTED BY, the other oversight seems serious enough to justify a back-patch. Discussion: https://postgr.es/m/3070.1581526786@sss.pgh.pa.us
-
Andres Freund authored
Looks like guaibasaurus had a autovacuum running during the controller_print_speculative_locks step (just added in 43e08419). Which does indeed seem quite possible. Avoid the problem by only looking for the backends participating in the test.
-
Michael Paquier authored
%d can be used to track if the current connection is in a transaction block or not, and adding it by default to the prompt has the advantage to not need a modification of .psqlrc, something not possible depending on the environment. This discussion has happened across various sources, and there was a strong consensus in favor of this change. Author: Vik Fearing Reviewed-by: Fabien Coelho Discussion: https://postgr.es/m/09502c40-cfe1-bb29-10f9-4b3fa7b2bbb2@2ndquadrant.com
-
Andres Freund authored
Previously, the speculative insert tests did not cover the case when a tuple t is inserted into a table with a unique index on a column but before it can insert into the index, a concurrent transaction has inserted a conflicting value into the index and the insertion of tuple t must be aborted. The basic permutation is one session successfully inserts into the table and an associated unique index while a concurrent session successfully inserts into the table but discovers a conflict before inserting into the index and must abort the insertion. Several variants on this include: - swap which session is successful - first session insert transaction does not commit, so second session must wait on a transaction lock - first session insert does not "complete", so second session must wait on a speculative insertion lock Also, refactor the existing TOAST table upsert test to be in the same spec and reuse the steps. Author: Melanie Plageman, Ashwin Agrawal, Andres Freund Reviewed-by: Andres Freund, Taylor Vesely Discussion: https://postgr.es/m/CAAKRu_ZRmxy_OEryfY3G8Zp01ouhgw59_-_Cm8n7LzRH5BAvng@mail.gmail.com
-
Fujii Masao authored
Commit caba97a9 changed pg_basebackup -F plain -R so that it overwrote postgresql.auto.conf in the backup, with new connection setting. This could cause the existing postgresql.auto.conf settings in the server to get lost unexpectedly. This is a bug. This commit fixes the bug by making pg_basebackup -F plain -R append the connection setting into postgresql.auto.conf in the backup. Author: Fujii Masao Reviewed-by: Sergei Kornilov Discussion: https://postgr.es/m/250dcf2a-94e7-c05e-824a-73cfb38a48a4@oss.nttdata.com
-
- 11 Feb, 2020 2 commits
-
-
Peter Eisentraut authored
-
Thomas Munro authored
This removes some lseek() system calls. Author: Thomas Munro Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGJ%2BoHhnvqjn3%3DHro7xu-YDR8FPr0FL6LF35kHRX%3D_bUzg%40mail.gmail.com
-
- 10 Feb, 2020 11 commits
-
-
Peter Eisentraut authored
-
Peter Eisentraut authored
This use was not protecting any unportable code, it was just omitting the code because it wouldn't be used. Remove the use to reduce code complexity a bit. Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com
-
Peter Eisentraut authored
The previous system had configure put the value into the makefiles and then have the makefiles pass them to the build of pg_config. That was put in place when pg_config was a shell script. We can simplify that by having configure put the value into pg_config.h directly. This also makes the standard build system match how the MSVC build system already does it. Discussion: https://www.postgresql.org/message-id/flat/6e457870-cef5-5f1d-b57c-fc89cfb8a788%402ndquadrant.com
-
Jeff Davis authored
Commit 4eaea3db introduced TupleHashTableHash(), but the signature didn't match the other exposed functions. Separate it into internal and external versions. The external version hides the details behind an API more consistent with the other external functions, and the internal version is still suitable for simplehash.
-
Alvaro Herrera authored
The original coding failed to quote the argument properly. Reported-by: Daniel Gustafsson Discussion: 1B8AE66C-85AB-4728-9BB4-612E8E61C219@yesql.se
-
Alvaro Herrera authored
Marking an object as dependant on an extension did not have any privilege check whatsoever; this allowed any user to mark objects as droppable by anyone able to DROP EXTENSION, which could be used to cause system-wide havoc. Disallow by checking that the calling user owns the mentioned object. (No constraints are placed on the extension.) Security: CVE-2020-1720 Reported-by: Tom Lane Discussion: 31605.1566429043@sss.pgh.pa.us
-
Michael Paquier authored
This reverts commit d1c0b613. The patch has some downsides that require more attention, as discussed with Noah Misch. Backpatch-through: 9.5
-
Amit Kapila authored
Reported-by: Justin Pryzby Author: Justin Pryzby Discussion: https://postgr.es/m/20200206021432.GA24549@telsasoft.com
-
Amit Kapila authored
Reported-by: Justin Pryzby Author: Justin Pryzby Backpatch-through: 9.6 Discussion: https://postgr.es/m/20200206021432.GA24549@telsasoft.com
-
Michael Paquier authored
The previous coding forgot to apply shell quoting to the socket directory and the data folder, leading to failures when running pg_upgrade. This refactors the code generating the pg_ctl command starting clusters to use a more correct shell quoting. Failures are easier to trigger in 12 and newer versions by using a value of --socketdir that includes quotes, but it is also possible to cause failures with quotes included in the default socket directory used by pg_upgrade or the data folders of the clusters involved in the upgrade. As 9.4 is going to be EOL'd with the next minor release, nobody is likely going to upgrade to it now so this branch is not included in the set of branches fixed. Author: Michael Paquier Reviewed-by: Álvaro Herrera, Noah Misch Backpatch-through: 9.5
-
Thomas Munro authored
The width of the invisible PROMPT2 must take into account, in order for user input to be aligned with the first line, that PROMPT1 can contain newlines. Author: Maxence Ahlouche Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAJeaomVyLSP_Wj%3D0FtYNTuoopWHyFarhUtYKDHs0HHv%2Bb%3DN9sA%40mail.gmail.com
-
- 09 Feb, 2020 2 commits
-
-
Tom Lane authored
This reverts commit 0e936a21. Per discussion, we can't change the section title without some web-site work, so revert this change temporarily. Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538@wrigleys.postgresql.org
-
Tom Lane authored
Commit b1071408 moved the GinPageSetDeleteXid() call to a spot where the "page" variable was pointing to the wrong page, causing the XID to be inserted on a page that's not being deleted, thus allowing later GinPageIsRecyclable tests to recycle the deleted page too soon. It might be a good idea to stop using the single "page" variable for multiple purposes in this function. But for the moment I just moved the GinPageSetDeleteXid() call down beside the GinPageSetDeleted() call, which seems like a more logical place for it anyway. Back-patch to v11, as the faulty patch was. (Fortunately, the bug hasn't made it into any release yet.) Discussion: https://postgr.es/m/21620.1581098806@sss.pgh.pa.us
-
- 07 Feb, 2020 12 commits
-
-
Alvaro Herrera authored
On a multi-level partioned table, when adding a partition not directly connected to the root table, foreign key constraints referencing the root were not cloned to the new partition, leading to the FK being possibly inadvertently violated later on. This was caused by fuzzy thinking in CloneFkReferenced (commit f56f8f8d): it was skipping constraints marked as having parents on the theory that cloning those would create duplicates; but that's only correct for the top level of the partitioning hierarchy. For levels below that one, such constraints must still be considered and only skipped if later on we see that we'd create duplicates. Apparently, I (Álvaro) wrote the comments right but the code implemented something slightly different. Author: Jehan-Guillaume de Rorthais Discussion: https://postgr.es/m/20200206004948.238352db@firost
-
Alvaro Herrera authored
When running TRUNCATE CASCADE on a child of a partitioned table referenced by another partitioned table, the truncate was not applied to partitions of the referencing table; this could leave rows violating the constraint in the referencing partitioned table. Repair by walking the pg_constraint chain all the way up to the topmost referencing table. Note: any partitioned tables containing FKs that reference other partitioned tables should be checked for possible violating rows, if TRUNCATE has occurred in partitions of the referenced table. Reported-by: Christophe Courtois Author: Jehan-Guillaume de Rorthais Discussion: https://postgr.es/m/20200204183906.115f693e@firost
-
Fujii Masao authored
Commit 147e3722 changed Tid scan so that it calls table_beginscan() and uses the scan option for seq scan. This change caused two issues. (1) The change caused Tid scan to take a predicate lock on the entire relation in serializable transaction even when relation-level lock is not necessary. This could lead to an unexpected serialization error. (2) The change caused Tid scan to increment the number of seq_scan in pg_stat_*_tables views even though it's not seq scan. This could confuse the users. This commit adds the scan option for Tid scan and makes Tid scan use it, to avoid those issues. Back-patch to v12, where the bug was introduced. Author: Tatsuhito Kasahara Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada, Fujii Masao Discussion: https://postgr.es/m/CAP0=ZVKy+gTbFmB6X_UW0pP3WaeJ-fkUWHoD-pExS=at3CY76g@mail.gmail.com
-
Andres Freund authored
The main benefit of doing so is that this allows llvm to ensure that types match - previously that'd only be detected by a crash within the called function. There were a number of cases where we passed a superfluous parameter... To avoid needing to add all the functions to llvmjit.{c,h}, instead get them from the llvm module for llvmjit_types.c. Also use that for the functions from llvmjit_types already in llvmjit.h. Author: Soumyadeep Chakraborty and Andres Freund Discussion: https://postgr.es/m/CADwEdooww3wZv-sXSfatzFRwMuwa186LyTwkBfwEW6NjtooBPA@mail.gmail.com
-
Michael Paquier authored
Oversight in commit b025f32e. Per private report from Julien Rouhaud.
-
Jeff Davis authored
Expose two new entry points: one for only calculating the hash value of a tuple, and another for looking up a hash entry when the hash value is already known. This will be useful for disk-based Hash Aggregation to avoid recomputing the hash value for the same tuple after saving and restoring it from disk. Discussion: https://postgr.es/m/37091115219dd522fd9ed67333ee8ed1b7e09443.camel%40j-davis.com
-
Andres Freund authored
This merges the code emission for a number of opcodes by handling the behavioural difference more locally. This reduces code, and also improves the generated code a bit in some cases, by removing redundant constants. Author: Andres Freund Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de
-
Andres Freund authored
Previously we used constant function pointer addresses, which prevents inlining and other related optimizations. Author: Andres Freund Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de
-
Andres Freund authored
It's already tracked via ExprState->parent, so we don't need to also include it in ExprEvalStep. When that code originally was written ExprState->parent didn't exist, but it since has been introduced in 6719b238. Author: Andres Freund Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de
-
Andres Freund authored
This mostly consists of using C99 style for loops, moving variables into narrower scopes, and a smattering of other minor improvements. Done separately to make it easier to review patches with actual functional changes. Author: Andres Freund Discussion: https://postgr.es/m/20191023163849.sosqbfs5yenocez3@alap3.anarazel.de
-
Michael Paquier authored
Author: Julien Rouhaud Discussion: https://postgr.es/m/20200206082333.GA95343@nol
-
Michael Paquier authored
This reverts commit 7bae0ad9, as this is not ideal with the tar format, and we may want to explore more options like what is done by tar with some equivalents of --owner and --group, but for pg_basebackup. Per complaints from Magnus Hagander and Stephen Frost. Discussion: https://postgr.es/m/20200205172259.GW3195@tamriel.snowman.net
-
- 06 Feb, 2020 2 commits
-
-
Michael Paquier authored
This reverts commit 41aadeeb, as the GUC checks could run on older values with the new values used, and result in incorrect errors if both parameters are changed at the same time. Per complaint from Tom Lane. Discussion: https://postgr.es/m/27574.1581015893@sss.pgh.pa.us Backpatch-through: 12
-
Peter Eisentraut authored
In certain transient states, it's possible that a table has attributes with attgenerated set but no default expressions in pg_attrdef yet. In that case, the old code path would not set relation->rd_att->constr->has_generated_stored, unless relation->rd_att->constr was also populated for some other reason. There was probably no practical impact, but it's better to keep this consistent. Reported-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/20200115181105.ad6ab6dlgyww3lb6%40alap3.anarazel.de
-