aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Add new simple TAP test for tablespaces.Thomas Munro2022-01-15
| | | | | | | | | | | The tablespace tests in the main regression tests have been changed to use "in-place" tablespaces, so that they work when streamed to a replica on the same host. Add a new TAP test that exercises tablespaces with absolute paths, for coverage. Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CA%2BhUKGKpRWQ9SxdxxDmTBCJoR0YnFpMBe7kyzY8SUQk%2BHeskxg%40mail.gmail.com
* Use in-place tablespaces in regression test.Thomas Munro2022-01-15
| | | | | | | | | | Remove the machinery from pg_regress that manages the testtablespace directory. Instead, use "in-place" tablespaces, because they work correctly when there is a streaming replica running on the same host. Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CA%2BhUKGKpRWQ9SxdxxDmTBCJoR0YnFpMBe7kyzY8SUQk%2BHeskxg%40mail.gmail.com
* Allow "in place" tablespaces.Thomas Munro2022-01-15
| | | | | | | | | | | | | Provide a developer-only GUC allow_in_place_tablespaces, disabled by default. When enabled, tablespaces can be created with an empty LOCATION string, meaning that they should be created as a directory directly beneath pg_tblspc. This can be used for new testing scenarios, in a follow-up patch. Not intended for end-user usage, since it might confuse backup tools that expect symlinks. Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CA%2BhUKGKpRWQ9SxdxxDmTBCJoR0YnFpMBe7kyzY8SUQk%2BHeskxg%40mail.gmail.com
* Rename value node fieldsPeter Eisentraut2022-01-14
| | | | | | | | | For the formerly-Value node types, rename the "val" field to a name specific to the node type, namely "ival", "fval", "sval", and "bsval". This makes some code clearer and catches mixups better. Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/8c1a2e37-c68d-703c-5a83-7a6077f4f997@enterprisedb.com
* Refactor AlterRole()Peter Eisentraut2022-01-14
| | | | | | | | | | | | Get rid of the three-valued logic for the Boolean variables to track whether the value was been specified and what the new value should be. Instead, we can use the "dfoo" variables to determine whether the value was specified and should be applied. This was already done in some cases, so this makes this more uniform and removes one layer of indirection. Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/8c1a2e37-c68d-703c-5a83-7a6077f4f997@enterprisedb.com
* Assert redirect pointers are sensible after heap_page_prune().Andres Freund2022-01-13
| | | | | | | | | | | | | | | | | Corruption of redirect item pointers often only becomes visible well after being corrupted, as e.g. bug #17255 shows: In the original reproducer, gigabyte of WAL were between the source of the corruption and the corruption becoming visible. To make it easier to find / prevent such bugs, verify whether redirect pointers are sensible at the end of heap_page_prune_execute(). 5cd7eb1f1c32 introduced related assertions while modifying the page, but they can't easily detect marking the target of an existing redirect as unused. Sometimes the corruption will be detected later, but that's harder to diagnose. Author: Andres Freund <andres@andres@anarazel.de> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20211122175914.ayk6gg6nvdwuhrzb@alap3.anarazel.de
* Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.Andres Freund2022-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since dc7420c2c92 the horizon used for pruning is determined "lazily". A more accurate horizon is built on-demand, rather than in GetSnapshotData(). If a horizon computation is triggered between two HeapTupleSatisfiesVacuum() calls for the same tuple, the result can change from RECENTLY_DEAD to DEAD. heap_page_prune() can process the same tid multiple times (once following an update chain, once "directly"). When the result of HeapTupleSatisfiesVacuum() of a tuple changes from RECENTLY_DEAD during the first access, to DEAD in the second, the "tuple is DEAD and doesn't chain to anything else" path in heap_prune_chain() can end up marking the target of a LP_REDIRECT ItemId unused. Initially not easily visible, Once the target of a LP_REDIRECT ItemId is marked unused, a new tuple version can reuse it. At that point the corruption may become visible, as index entries pointing to the "original" redirect item, now point to a unrelated tuple. To fix, compute HTSV for all tuples on a page only once. This fixes the entire class of problems of HTSV changing inside heap_page_prune(). However, visibility changes can obviously still occur between HTSV checks inside heap_page_prune() and outside (e.g. in lazy_scan_prune()). The computation of HTSV is now done in bulk, in heap_page_prune(), rather than on-demand in heap_prune_chain(). Besides being a bit simpler, it also is faster: Memory accesses can happen sequentially, rather than in the order of HOT chains. There are other causes of HeapTupleSatisfiesVacuum() results changing between two visibility checks for the same tuple, even before dc7420c2c92. E.g. HEAPTUPLE_INSERT_IN_PROGRESS can change to HEAPTUPLE_DEAD when a transaction aborts between the two checks. None of the these other visibility status changes are known to cause corruption, but heap_page_prune()'s approach makes it hard to be confident. A patch implementing a more fundamental redesign of heap_page_prune(), which fixes this bug and simplifies pruning substantially, has been proposed by Peter Geoghegan in https://postgr.es/m/CAH2-WzmNk6V6tqzuuabxoxM8HJRaWU6h12toaS-bqYcLiht16A@mail.gmail.com However, that redesign is larger change than desirable for backpatching. As the new design still benefits from the batched visibility determination introduced in this commit, it makes sense to commit this narrower fix to 14 and master, and then commit Peter's improvement in master. The precise sequence required to trigger the bug is complicated and hard to do exercise in an isolation test (until we have wait points). Due to that the isolation test initially posted at https://postgr.es/m/20211119003623.d3jusiytzjqwb62p%40alap3.anarazel.de and updated in https://postgr.es/m/20211122175914.ayk6gg6nvdwuhrzb%40alap3.anarazel.de isn't committable. A followup commit will introduce additional assertions, to detect problems like this more easily. Bug: #17255 Reported-By: Alexander Lakhin <exclusion@gmail.com> Debugged-By: Andres Freund <andres@anarazel.de> Debugged-By: Peter Geoghegan <pg@bowt.ie> Author: Andres Freund <andres@andres@anarazel.de> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20211122175914.ayk6gg6nvdwuhrzb@alap3.anarazel.de Backpatch: 14-, the oldest branch containing dc7420c2c92
* Fix ruleutils.c's dumping of whole-row Vars in more contexts.Tom Lane2022-01-13
| | | | | | | | | | | | | | | | | | Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it missed the case of INSERT with a single-row VALUES, as reported by Timur Khanjanov. Nosing around ruleutils.c, I found a second oversight: the code for RowCompareExpr generates ROW() notation without benefit of an actual RowExpr, and naturally it wasn't in sync :-(. (The code for FieldStore also does this, but we don't expect that to generate strictly parsable SQL anyway, so I left it alone.) Back-patch to all supported branches. Discussion: https://postgr.es/m/efaba6f9-4190-56be-8ff2-7a1674f9194f@intrans.baku.az
* Improve error handling of HMAC computationsMichael Paquier2022-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is similar to b69aba7, except that this completes the work for HMAC with a new routine called pg_hmac_error() that would provide more context about the type of error that happened during a HMAC computation: - The fallback HMAC implementation in hmac.c relies on cryptohashes, so in some code paths it is necessary to return back the error generated by cryptohashes. - For the OpenSSL implementation (hmac_openssl.c), the logic is very similar to cryptohash_openssl.c, where the error context comes from OpenSSL if one of its internal routines failed, with different error codes if something internal to hmac_openssl.c failed or was incorrect. Any in-core code paths that use the centralized HMAC interface are related to SCRAM, for errors that are unlikely going to happen, with only SHA-256. It would be possible to see errors when computing some HMACs with MD5 for example and OpenSSL FIPS enabled, and this commit would help in reporting the correct errors but nothing in core uses that. So, at the end, no backpatch to v14 is done, at least for now. Errors in SCRAM related to the computation of the server key, stored key, etc. need to pass down the potential error context string across more layers of their respective call stacks for the frontend and the backend, so each surrounding routine is adapted for this purpose. Reviewed-by: Sergey Shinderuk Discussion: https://postgr.es/m/Yd0N9tSAIIkFd+qi@paquier.xyz
* Fix incorrect comments in hmac.c and hmac_openssl.cMichael Paquier2022-01-13
| | | | | | | | | Both files referred to pg_hmac_ctx->data, which, I guess, comes from the early versions of the patch that has resulted in commit e6bdfd9. Author: Sergey Shinderuk Discussion: https://postgr.es/m/8cbb56dd-63d6-a581-7a65-25a97ac4be03@postgrespro.ru Backpatch-through: 14
* Fix memory leak in indexUnchanged hint mechanism.Peter Geoghegan2022-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9dc718bd added a "logically unchanged by UPDATE" hinting mechanism, which is currently used within nbtree indexes only (see commit d168b666). This mechanism determined whether or not the incoming item is a logically unchanged duplicate (a duplicate needed only for MVCC versioning purposes) once per row updated per non-HOT update. This approach led to memory leaks which were noticeable with an UPDATE statement that updated sufficiently many rows, at least on tables that happen to have an expression index. On HEAD, fix the issue by adding a cache to the executor's per-index IndexInfo struct. Take a different approach on Postgres 14 to avoid an ABI break: simply pass down the hint to all indexes unconditionally with non-HOT UPDATEs. This is deemed acceptable because the hint is currently interpreted within btinsert() as "perform a bottom-up index deletion pass if and when the only alternative is splitting the leaf page -- prefer to delete any LP_DEAD-set items first". nbtree must always treat the hint as a noisy signal about what might work, as a strategy of last resort, with costs imposed on non-HOT updaters. (The same thing might not be true within another index AM that applies the hint, which is why the original behavior is preserved on HEAD.) Author: Peter Geoghegan <pg@bowt.ie> Reported-By: Klaudie Willis <Klaudie.Willis@protonmail.com> Diagnosed-By: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/261065.1639497535@sss.pgh.pa.us Backpatch: 14-, where the hinting mechanism was added.
* vacuumlazy.c: fix "garbage tuples" reference.Peter Geoghegan2022-01-12
| | | | Another minor oversight in commit 4f8d9d12.
* Consider fractional paths in generate_orderedappend_pathsTomas Vondra2022-01-12
| | | | | | | | | | | | | | | | | | | When building append paths, we've been looking only at startup and total costs for the paths. When building fractional paths that may eliminate the cheapest one, because it may be dominated by two separate paths (one for startup, one for total cost). This extends generate_orderedappend_paths() to also consider which paths have lowest fractional cost. Currently we only consider paths matching pathkeys - in the future this may be improved by also considering paths that are only partially sorted, with an incremental sort on top. Original report of an issue by Arne Roland, patch by me (based on a suggestion by Tom Lane). Reviewed-by: Arne Roland, Zhihong Yu Discussion: https://postgr.es/m/e8f9ec90-546d-e948-acce-0525f3e92773%40enterprisedb.com Discussion: https://postgr.es/m/1581042da8044e71ada2d6e3a51bf7bb%40index.de
* Add index on pg_publication_rel.prpubidAlvaro Herrera2022-01-12
| | | | | | | | | | This should have been added for the benefit of GetPublicationRelations; let's add it now. I couldn't measure a performance difference in the TAP tests, but that may be because the tests use very few publications. Discussion: https://postgr.es/m/202201120041.p24wvsfcsope@alvherre.pgsql
* ecpg: Catch zero-length Unicode identifiers correctlyPeter Eisentraut2022-01-12
| | | | | | | | | | | | The previous code to detect a zero-length identifier when using Unicode identifiers such as exec sql select u&""; did not work. This fixes that. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/82fafa79-331c-9d65-e51b-8b5d1b2383fc%40enterprisedb.com
* Move any code specific to log_destination=csvlog to its own fileMichael Paquier2022-01-12
| | | | | | | | | | | | The recent refactoring done in ac7c807 makes this move possible and simple, as this just moves some code around. This reduces the size of elog.c by 7%. Author: Michael Paquier, Sehrope Sarkuni Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com simply moves the routines related to csvlog into their own file
* Refactor set of routines specific to elog.cMichael Paquier2022-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | This refactors the following routines and facilities coming from elog.c, to ease their use across multiple log destinations: - Start timestamp, including its reset, to store when a process has been started. - The log timestamp, associated to an entry (the same timestamp is used when logging across multiple destinations). - Routine deciding if a query can be logged or not. - The backend type names, depending on the process that logs any information (postmaster, bgworker name or just GetBackendTypeDesc() with a regular backend). - Write of logs using the logging piped protocol, with the log collector enabled. - Error severity converted to a string. These refactored routines will be used for some follow-up changes to move all the csvlog logic into its own file and to potentially add JSON as log destination, reducing the overall size of elog.c as the end result. Author: Michael Paquier, Sehrope Sarkuni Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com
* Fix comment related to pg_cryptohash_error()Michael Paquier2022-01-12
| | | | | | | | | One of the comments introduced in b69aba7 was worded a bit weirdly, so improve it. Reported-by: Sergey Shinderuk Discussion: https://postgr.es/m/71b9a5d2-a3bf-83bc-a243-93dcf0bcfb3b@postgrespro.ru Backpatch-through: 14
* Add missing include guard to win32ntdll.h.Thomas Munro2022-01-12
| | | | | | | | | Oversight in commit e2f0f8ed. Also add this file to the exclusion lists in headerscheck and cpluscpluscheck, because Unix systems don't have a header it includes. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2760528.1641929756%40sss.pgh.pa.us
* Improve error message for missing extension.Tom Lane2022-01-11
| | | | | | | | | | | | | | If we get ENOENT while trying to read an extension control file, report that as a missing extension (with a HINT to install it) rather than as a filesystem access problem. The message wording was extensively bikeshedded in hopes of pointing people to the idea that they need to do a software installation before they can install the extension into the current database. Nathan Bossart, with review/wording suggestions from Daniel Gustafsson, Chapman Flack, and myself Discussion: https://postgr.es/m/3950D56A-4E47-48E7-BF9B-F5F22E268BE7@amazon.com
* Clean up messy API for src/port/thread.c.Tom Lane2022-01-11
| | | | | | | | | | | | | | | | | | | | | | | The point of this patch is to reduce inclusion spam by not needing to #include <netdb.h> or <pwd.h> in port.h (which is read by every compile in our tree). To do that, we must remove port.h's declarations of pqGetpwuid and pqGethostbyname. pqGethostbyname is only used, and is only ever likely to be used, in src/port/getaddrinfo.c --- which isn't even built on most platforms, making pqGethostbyname dead code for most people. Hence, deal with that by just moving it into getaddrinfo.c. To clean up pqGetpwuid, invent a couple of simple wrapper functions with less-messy APIs. This allows removing some duplicate error-handling code, too. In passing, remove thread.c from the MSVC build, since it contains nothing we use on Windows. Noted while working on 376ce3e40. Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
* Improve warning message in pg_signal_backend()John Naylor2022-01-11
| | | | | | | | | | | | Previously, invoking pg_terminate_backend() or pg_cancel_backend() with the postmaster PID produced a "PID XXXX is not a PostgresSQL server process" warning, which does not make sense. Change to "backend process" to make the message more exact. Nathan Bossart, based on an idea from Bharath Rupireddy with input from Tom Lane and Euler Taveira Discussion: https://www.postgresql.org/message-id/flat/CALj2ACW7Rr-R7mBcBQiXWPp=JV5chajjTdudLiF5YcpW-BmHhg@mail.gmail.com
* Clean up error message reported after \password encryption failure.Tom Lane2022-01-11
| | | | | | | | | | | | | | | Experimenting with FIPS mode enabled, I saw regression=# \password joe Enter new password for user "joe": Enter it again: could not encrypt password: disabled for FIPS out of memory because PQencryptPasswordConn was still of the opinion that "out of memory" is always appropriate to print. Minor oversight in b69aba745. Like that one, back-patch to v14.
* Enhance pg_log_backend_memory_contexts() for auxiliary processes.Fujii Masao2022-01-11
| | | | | | | | | | | | | | | | | | Previously pg_log_backend_memory_contexts() could request to log the memory contexts of backends, but not of auxiliary processes such as checkpointer. This commit enhances the function so that it can also send the request to auxiliary processes. It's useful to look at the memory contexts of those processes for debugging purpose and better understanding of the memory usage pattern of them. Note that pg_log_backend_memory_contexts() cannot send the request to logger or statistics collector. Because this logging request mechanism is based on shared memory but those processes aren't connected to that. Author: Bharath Rupireddy Reviewed-by: Vignesh C, Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/CALj2ACU1nBzpacOK2q=a65S_4+Oaz_rLTsU1Ri0gf7YUmnmhfQ@mail.gmail.com
* Fix typo in rewriteheap.c.Amit Kapila2022-01-11
| | | | | Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACW7SvfFW8r2uKH6oQm1kNpt8aQMG61kSBPK0S2PHhFbMw@mail.gmail.com
* Improve error handling of cryptohash computationsMichael Paquier2022-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing cryptohash facility was causing problems in some code paths related to MD5 (frontend and backend) that relied on the fact that the only type of error that could happen would be an OOM, as the MD5 implementation used in PostgreSQL ~13 (the in-core implementation is used when compiling with or without OpenSSL in those older versions), could fail only under this circumstance. The new cryptohash facilities can fail for reasons other than OOMs, like attempting MD5 when FIPS is enabled (upstream OpenSSL allows that up to 1.0.2, Fedora and Photon patch OpenSSL 1.1.1 to allow that), so this would cause incorrect reports to show up. This commit extends the cryptohash APIs so as callers of those routines can fetch more context when an error happens, by using a new routine called pg_cryptohash_error(). The error states are stored within each implementation's internal context data, so as it is possible to extend the logic depending on what's suited for an implementation. The default implementation requires few error states, but OpenSSL could report various issues depending on its internal state so more is needed in cryptohash_openssl.c, and the code is shaped so as we are always able to grab the necessary information. The core code is changed to adapt to the new error routine, painting more "const" across the call stack where the static errors are stored, particularly in authentication code paths on variables that provide log details. This way, any future changes would warn if attempting to free these strings. The MD5 authentication code was also a bit blurry about the handling of "logdetail" (LOG sent to the postmaster), so improve the comments related that, while on it. The origin of the problem is 87ae969, that introduced the centralized cryptohash facility. Extra changes are done for pgcrypto in v14 for the non-OpenSSL code path to cope with the improvements done by this commit. Reported-by: Michael Mühlbeyer Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/89B7F072-5BBE-4C92-903E-D83E865D9367@trivadis.com Backpatch-through: 14
* Avoid warning about uninitialized value in MSVC python3 testsAndrew Dunstan2022-01-10
| | | | | | Juan José Santamaría Flecha Backpatch to all live branches
* Make EXEC_BACKEND more convenient on Linux and FreeBSD.Thomas Munro2022-01-11
| | | | | | | | | | Try to disable ASLR when building in EXEC_BACKEND mode, to avoid random memory mapping failures while testing. For developer use only, no effect on regular builds. Suggested-by: Andres Freund <andres@anarazel.de> Tested-by: Bossart, Nathan <bossartn@amazon.com> Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de
* Rename functions to avoid future conflictsPeter Eisentraut2022-01-10
| | | | | | | | | Rename range_serialize/range_deserialize to brin_range_serialize/brin_range_deserialize, since there are already public range_serialize/range_deserialize in rangetypes.h. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Discussion: https://www.postgresql.org/message-id/CA+renyX0ipvY6A_jUOHeB1q9mL4bEYfAZ5FBB7G7jUo5bykjrA@mail.gmail.com
* Prefer $HOME when looking up the current user's home directory.Tom Lane2022-01-09
| | | | | | | | | | | | | | | When we need to identify the home directory on non-Windows, first consult getenv("HOME"). If that's empty or unset, fall back on our previous method of checking the <pwd.h> database. Preferring $HOME allows the user to intentionally point at some other directory, and it seems to be in line with the behavior of most other utilities. However, we shouldn't rely on it completely, as $HOME is likely to be unset when running as a daemon. Anders Kaseorg Discussion: https://postgr.es/m/1634252654444.90107@mit.edu
* Make pg_get_expr() more bulletproof.Tom Lane2022-01-09
| | | | | | | | | | | | | | | | | | | | | | Since this function is defined to accept pg_node_tree values, it could get applied to any nodetree that can appear in a cataloged pg_node_tree column. Some such cases can't be supported --- for example, its API doesn't allow providing referents for more than one relation --- but we should try to throw a user-facing error rather than an internal error when encountering such a case. In support of this, extend expression_tree_walker/mutator to be sure they'll work on any such node tree (which basically means adding support for relpartbound node types). That allows us to run pull_varnos and check for the case of multiple relations before we start processing the tree. The alternative of changing the low-level error thrown for an out-of-range varno isn't appealing, because that could mask actual bugs in other usages of ruleutils. Per report from Justin Pryzby. This is basically cosmetic, so no back-patch. Discussion: https://postgr.es/m/20211219205422.GT17618@telsasoft.com
* More cleanup of a2ab9c06ea.Jeff Davis2022-01-08
| | | | | | | | | | | | | | Require SELECT privileges when performing UPDATE or DELETE, to be consistent with the way a normal UPDATE or DELETE command works. Simplify subscription test it so that it runs faster. Also, wait for initial table sync to complete to avoid intermittent failures. Minor doc fixup. Discussion: https://postgr.es/m/CAA4eK1L3-qAtLO4sNGaNhzcyRi_Ufmh2YPPnUjkROBK0tN%3Dx%3Dg%40mail.gmail.com Discussion: https://postgr.es/m/1514479.1641664638%40sss.pgh.pa.us Discussion: https://postgr.es/m/Ydkfj5IsZg7mQR0g@paquier.xyz
* Fix pgperlcritic complaint, per buildfarm.Jeff Davis2022-01-08
| | | | | Author: Michael Paquier Discussion: https://postgr.es/m/YdlYfS/l%2BPQA0ehs%40paquier.xyz
* Fix issues with describe queries of extended statistics in psqlMichael Paquier2022-01-08
| | | | | | | | | | | | | | | | This addresses some problems in the describe queries used for extended statistics: - Two schema qualifications for the text type were missing for \dX. - The list of extended statistics listed for a table through \d was ordered based on the object OIDs, but it is more consistent with the other commands to order by namespace and then by object name. - A couple of aliases were not used in \d. These are removed. This is similar to commits 1f092a3 and 07f8a9e. Author: Justin Pryzby Discussion: https://postgr.es/m/20220107022235.GA14051@telsasoft.com Backpatch-through: 14
* Respect permissions within logical replication.Jeff Davis2022-01-07
| | | | | | | | | | | | | | | | | | | | Prevent logical replication workers from performing insert, update, delete, truncate, or copy commands on tables unless the subscription owner has permission to do so. Prevent subscription owners from circumventing row-level security by forbidding replication into tables with row-level security policies which the subscription owner is subject to, without regard to whether the policy would ordinarily allow the INSERT, UPDATE, DELETE or TRUNCATE which is being replicated. This seems sufficient for now, as superusers, roles with bypassrls, and target table owners should still be able to replicate despite RLS policies. We can revisit the question of applying row-level security policies on a per-row basis if this restriction proves too severe in practice. Author: Mark Dilger Reviewed-by: Jeff Davis, Andrew Dunstan, Ronan Dunklau Discussion: https://postgr.es/m/9DFC88D3-1300-4DE8-ACBC-4CEF84399A53%40enterprisedb.com
* Fix thinko coming from 000f3adfMichael Paquier2022-01-08
| | | | | | | | | | | | | pg_basebackup.c relies on the compression level to not be 0 to decide if compression should be used, but 000f3adf missed the fact that the default compression (Z_DEFAULT_COMPRESSION) is -1, which would be used if specifying --gzip without --compress. While on it, add some coverage for --gzip, as this is rather easy to miss. Reported-by: Christoph Berg Discussion: https://postgr.es/m/YdhRDMLjabtXOnhY@msg.df7cb.de
* Update copyright for 2022Bruce Momjian2022-01-07
| | | | Backpatch-through: 10
* Allow MSVC .bat wrappers to be called from anywhereAndrew Dunstan2022-01-07
| | | | | | | | | | | | Instead of using a hardcoded or default path to the perl file the .bat file is a wrapper for, we use a path that means the file is found in the same directory as the .bat file. Patch by Anton Voloshin, slightly tweaked by me. Backpatch to all live branches Discussion: https://postgr.es/m/2b7a674b-5fb0-d264-75ef-ecc7a31e54f8@postgrespro.ru
* Skip install/test of pgcrypto on MSVC when not built with opensslAndrew Dunstan2022-01-07
| | | | | | Commit db7d1a7b05 missed a couple of places that needed adjustment now we are not building pgcrypto when openssl is not configured, causing contrib installcheck to fail in such a case.
* Fix comment in fe-connect.c about PQping and pg_ctlMichael Paquier2022-01-07
| | | | | | | | Since f13ea95f, pg_ctl does not use PQping(), but one comment did not get the call. Author: Euler Taveira Discussion: https://postgr.es/m/4b1deb4a-2771-416d-9710-ccd2fa66f058@www.fastmail.com
* Add TAP tests for pg_basebackup with compressionMichael Paquier2022-01-07
| | | | | | | | | | | | | pg_basebackup is able to use gzip to compress the contents of backups with the tar format, but there were no tests for that. This adds a minimalistic set of tests to check the contents of such base backups, including sanity checks on the contents generated with gzip commands. The tests are skipped if Postgres is compiled --without-zlib, and the checks based on the gzip command are skipped if nothing can be found, following the same model as the existing tests for pg_receivewal. Reviewed-by: Georgios Kokolatos Discussion: https://postgr.es/m/Yb3GEgWwcu4wZDuA@paquier.xyz
* Refactor tar method of walmethods.c to rely on the compression methodMichael Paquier2022-01-07
| | | | | | | | | | | | | | | | | | | | Since d62bcc8, the directory method of walmethods.c uses the compression method to determine which code path to take. The tar method, used by pg_basebackup --format=t, was inconsistent regarding that, as it relied on the compression level to check if no compression or gzip should be used. This commit makes the code more consistent as a whole in this file, making the tar logic use a compression method rather than assigning COMPRESSION_NONE that would be ignored. The options of pg_basebackup are planned to be reworked but we are not sure yet of the shape they should have as this has some dependency with the integration of the server-side compression for base backups, so this is left out for the moment. This change has as benefit to make easier the future integration of new compression methods for the tar method of walmethods.c, for the client-side compression. Reviewed-by: Georgios Kokolatos Discussion: https://postgr.es/m/Yb3GEgWwcu4wZDuA@paquier.xyz
* Prevent altering partitioned table's rowtype, if it's used elsewhere.Tom Lane2022-01-06
| | | | | | | | | | | | | | We disallow altering a column datatype within a regular table, if the table's rowtype is used as a column type elsewhere, because we lack code to go around and rewrite the other tables. This restriction should apply to partitioned tables as well, but it was not checked because ATRewriteTables and ATPrepAlterColumnType were not on the same page about who should do it for which relkinds. Per bug #17351 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/17351-6db1870f3f4f612a@postgresql.org
* Extend psql's \lo_list/\dl to be able to print large objects' ACLs.Tom Lane2022-01-06
| | | | | | | | | | | | The ACL is printed when you add + to the command, similarly to various other psql backslash commands. Along the way, move the code for this into describe.c, where it is a better fit (and can share some code). Pavel Luzanov, reviewed by Georgios Kokolatos Discussion: https://postgr.es/m/6d722115-6297-bc53-bb7f-5f150e765299@postgrespro.ru
* On second thought, remove regex.linux.utf8 regression test altogether.Tom Lane2022-01-05
| | | | | | | | The code-coverage report says that this test doesn't increase coverage by one single line, which I now realize is because I made src/test/modules/test_regex/sql/test_regex_utf8.sql to cover all the code that this would. So really it's pointless and we should just drop it.
* Enable routine running of regex.linux.utf8 regression test.Tom Lane2022-01-05
| | | | | | | Up to now this has just sat there as a test you could invoke via EXTRA_TESTS, which of course nobody does. I'm feeling encouraged because c2e8bd275 hasn't yet broke anything, so let's try making this run with a suitable guard condition (similar to collate.linux.utf8).
* Create foreign key triggers in partitioned tables tooAlvaro Herrera2022-01-05
| | | | | | | | | | | | | | | | | | | | | | | | | | While user-defined triggers defined on a partitioned table have a catalog definition for both it and its partitions, internal triggers used by foreign keys defined on partitioned tables only have a catalog definition for its partitions. This commit fixes that so that partitioned tables get the foreign key triggers too, just like user-defined triggers. Moreover, like user-defined triggers, partitions' internal triggers will now also have their tgparentid set appropriately. This is to allow subsequent commit(s) to make the foreign key related events to be fired in some cases using the parent table triggers instead of those of partitions'. This also changes what tgisinternal means in some cases. Currently, it means either that the trigger is an internal implementation object of a foreign key constraint, or a "child" trigger on a partition cloned from the trigger on the parent. This commit changes it to only mean the former to avoid confusion. As for the latter, it can be told by tgparentid being nonzero, which is now true both for user- defined and foreign key's internal triggers. Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Arne Roland <A.Roland@index.de> Discussion: https://postgr.es/m/CA+HiwqG7LQSK+n8Bki8tWv7piHD=PnZro2y6ysU2-28JS6cfgQ@mail.gmail.com
* Reduce relcache access in WAL sender streaming logical changesMichael Paquier2022-01-05
| | | | | | | | | | | | | | | | | | | | | | get_rel_sync_entry(), which is called each time a change needs to be logically replicated, is a rather hot code path in the WAL sender sending logical changes. This code path was doing a relcache access on relkind and relpartition for each logical change, but we only need to know this information when building or re-building the cached information for a relation. Some measurements prove that this is noticeable in perf profiles, particularly when attempting to replicate changes from relations that are not published as these cause less overhead in the WAL sender, delaying further the replication of changes for relations that are published. Issue introduced in 83fd453. Author: Hou Zhijie Reviewed-by: Kyotaro Horiguchi, Euler Taveira Discussion: https://postgr.es/m/OS0PR01MB5716E863AA9E591C1F010F7A947D9@OS0PR01MB5716.jpnprd01.prod.outlook.com Backpatch-through: 13
* Remove redundant initialization of BrinMemTuple.Tom Lane2022-01-04
| | | | | | | | | brin_new_memtuple already did this, so there's no need for initialize_brin_buildstate to do it again. Richard Guo, reviewed by Bharath Rupireddy Discussion: https://postgr.es/m/CAMbWs4-kYYpKNOdiWtsCZ3jbkFFj4nhOVH22JH7dsrMYX=aGjg@mail.gmail.com
* Fix silly mistake in AssertAlvaro Herrera2022-01-04
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-30 21:35:50 +0000