aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Enforce foreign key correctly during cross-partition updatesAlvaro Herrera2022-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an update on a partitioned table referenced in foreign key constraints causes a row to move from one partition to another, the fact that the move is implemented as a delete followed by an insert on the target partition causes the foreign key triggers to have surprising behavior. For example, a given foreign key's delete trigger which implements the ON DELETE CASCADE clause of that key will delete any referencing rows when triggered for that internal DELETE, although it should not, because the referenced row is simply being moved from one partition of the referenced root partitioned table into another, not being deleted from it. This commit teaches trigger.c to skip queuing such delete trigger events on the leaf partitions in favor of an UPDATE event fired on the root target relation. Doing so is sensible because both the old and the new tuple "logically" belong to the root relation. The after trigger event queuing interface now allows passing the source and the target partitions of a particular cross-partition update when registering the update event for the root partitioned table. Along with the two ctids of the old and the new tuple, the after trigger event now also stores the OIDs of those partitions. The tuples fetched from the source and the target partitions are converted into the root table format, if necessary, before they are passed to the trigger function. The implementation currently has a limitation that only the foreign keys pointing into the query's target relation are considered, not those of its sub-partitioned partitions. That seems like a reasonable limitation, because it sounds rare to have distinct foreign keys pointing to sub-partitioned partitions instead of to the root table. This misbehavior stems from commit f56f8f8da6af (which added support for foreign keys to reference partitioned tables) not paying sufficient attention to commit 2f178441044b (which had introduced cross-partition updates a year earlier). Even though the former commit goes back to Postgres 12, we're not backpatching this fix at this time for fear of destabilizing things too much, and because there are a few ABI breaks in it that we'd have to work around in older branches. It also depends on commit f4566345cf40, which had its own share of backpatchability issues as well. Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reported-by: Eduard Català <eduard.catala@gmail.com> Discussion: https://postgr.es/m/CA+HiwqFvkBCmfwkQX_yBqv2Wz8ugUGiBDxum8=WvVbfU1TXaNg@mail.gmail.com Discussion: https://postgr.es/m/CAL54xNZsLwEM1XCk5yW9EqaRzsZYHuWsHQkA2L5MOSKXAwviCQ@mail.gmail.com
* Fix global ICU collations for ICU < 54Peter Eisentraut2022-03-20
| | | | | | | | | | | | | | | | | createdb() didn't check for collation attributes validity, which has to be done explicitly on ICU < 54. It also forgot to close the ICU collator opened during the check which leaks some memory. To fix both, add a new check_icu_locale() that does all the appropriate verification and close the ICU collator. initdb also had some partial check for ICU < 54. To have consistent error reporting across major ICU versions, and get rid of the need to include ucol.h, remove the partial check there. The backend will report an error if needed during the post-boostrap iniitialization phase. Author: Julien Rouhaud <julien.rouhaud@free.fr> Discussion: https://www.postgresql.org/message-id/20220319041459.qqqiqh335sga5ezj@jrouhaud
* pgstat: split out WAL handling from pgstat_{initialize,report_stat}.Andres Freund2022-03-19
| | | | | | | | | A later commit will move the handling of the different kinds of stats into separate files. By splitting out WAL handling in this commit that later move will just move code around without other changes. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
* pgstat: split relation, database handling out of pgstat_report_stat().Andres Freund2022-03-19
| | | | | | | | | | | | pgstat_report_stat() handles several types of stats, yet relation stats have so far been handled directly in pgstat_report_stat(). A later commit will move the handling of the different kinds of stats into separate files. By splitting out relation handling in this commit that later move will just move code around without other changes. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
* pgstat: run pgindent on pgstat.c/h.Andres Freund2022-03-19
| | | | | | | | Upcoming commits will touch a lot of the pgstats code. Reindenting separately makes it easier to keep the code in a well-formatted shape each step. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
* Fix an outdated and grammatically wrong commentAlvaro Herrera2022-03-19
| | | | | Authored by Amit Langote and myself independently Discussion: https://postgr.es/m/CA+HiwqGCjcH0gG-=tM7hhP7TEDmzrHMHJbPGSHtHgFmx9mnFkg@mail.gmail.com
* Improve handling of SET ACCESS METHOD for ALTER MATERIALIZED VIEWMichael Paquier2022-03-19
| | | | | | | | | | | | | b048326 has added support for SET ACCESS METHOD in ALTER TABLE, but it has missed a few things for materialized views: - No documentation for this clause on the ALTER MATERIALIZED VIEW page. - psql tab completion missing. - No regression tests. This commit closes the gap on all the points listed above. Author: Yugo Nagata Discussion: https://postgr.es/m/20220316133337.5dc9740abfa24c25ec9f67f5@sraoss.co.jp
* Add regression tests for ALTER MATERIALIZED VIEW with tablespacesMichael Paquier2022-03-19
| | | | | | | | | | The clauses SET TABLESPACE and ALL IN TABLESPACE are supported in ALTER MATERIALIZED VIEW for a long time, and they behave mostly like ALTER TABLE by reusing the same code paths, but there were zero tests for them. This commit closes the gap with new tests in tablespace.sql. Author: Yugo Nagata Discussion: https://postgr.es/m/20220316133337.5dc9740abfa24c25ec9f67f5@sraoss.co.jp
* Silence -Wmaybe-uninitialized compiler warning in dbcommands.c.Andres Freund2022-03-18
| | | | | | | Introduced in f2553d43060e. See also 3f6b3be39ca9, which did so for nearby variables. Discussion: https://postgr.es/m/20220319014707.kgtomqdzm6m2ulro@alap3.anarazel.de
* Fix incorrect xmlschema output for types timetz and timestamptz.Tom Lane2022-03-18
| | | | | | | | | | | The output of table_to_xmlschema() and allied functions includes a regex describing valid values for these types ... but the regex was itself invalid, as it failed to escape a literal "+" sign. Report and fix by Renan Soares Lopes. Back-patch to all supported branches. Discussion: https://postgr.es/m/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com
* Specify database encoding in new ICU test.Tom Lane2022-03-18
| | | | | | | Otherwise, the database encoding varies depending on the user's environment, and so the test might fail depending on whether ICU likes the encoding. In particular, the test fails completely if the prevailing locale is C.
* Doc: remove bogus instruction to install contrib/hstore.Tom Lane2022-03-18
| | | | | This test suite does not use hstore. Looks like this text was copied-and-pasted from src/test/subscription/README.
* Remove workarounds for avoiding [U]INT64_FORMAT in translatable strings.Tom Lane2022-03-18
| | | | | | | | | | Update pg_backup_tar.c along the same lines as 62aa2bb29 and other previous cleanup: we can now rely on %lld or %llu as long as we explicitly cast to long long or unsigned long long. Japin Li Discussion: https://postgr.es/m/MEYP282MB16694F7CC1B119B4ECDD8CBEB6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
* Add circular WAL decoding buffer, take II.Thomas Munro2022-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach xlogreader.c to decode the WAL into a circular buffer. This will support optimizations based on looking ahead, to follow in a later commit. * XLogReadRecord() works as before, decoding records one by one, and allowing them to be examined via the traditional XLogRecGetXXX() macros and certain traditional members like xlogreader->ReadRecPtr. * An alternative new interface XLogReadAhead()/XLogNextRecord() is added that returns pointers to DecodedXLogRecord objects so that it's now possible to look ahead in the WAL stream while replaying. * In order to be able to use the new interface effectively while streaming data, support is added for the page_read() callback to respond to a new nonblocking mode with XLREAD_WOULDBLOCK instead of waiting for more data to arrive. No direct user of the new interface is included in this commit, though XLogReadRecord() uses it internally. Existing code doesn't need to change, except in a few places where it was accessing reader internals directly and now needs to go through accessor macros. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Reviewed-by: Andres Freund <andres@anarazel.de> (earlier versions) Discussion: https://postgr.es/m/CA+hUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq=AovOddfHpA@mail.gmail.com
* Fix header inclusion order in pg_receivewal.cMichael Paquier2022-03-18
| | | | | | | | | | | lz4frame.h was getting declared after the headers specific to Postgres, but it needs to be included between postgres_fe.h and the internal headers. Issue introduced by babbbb5. Reported-by: Justin Prysby Discussion: https://postgr.es/m/20220317111220.GI28503@telsasoft.com
* Declare aarch64 has single copy atomicity for 8 byte values.Thomas Munro2022-03-18
| | | | | | | | | | | | | | | | | | | | | | Architecture Reference Manual for ARMv8 B2.2.1 [1] For explicit memory effects generated from an Exception level the following rules apply: - A read that is generated by a load instruction that loads a single general-purpose register and is aligned to the size of the read in the instruction is single-copy atomic. - A write that is generated by a store instruction that stores a single general-purpose register and is aligned to the size of the write in the instruction is single-copy atomic. [1] https://documentation-service.arm.com/static/61fbe8f4fa8173727a1b734e https://developer.arm.com/documentation/ddi0487/latest Author: Yura Sokolov <y.sokolov@postgrespro.ru> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Discussion: https://postgr.es/m/f7f3f0febe27862711f924a7b0f39e065e547f4b.camel%40postgrespro.ru Discussion: https://postgr.es/m/CA%2BhUKGKyJf7kwYkqDgzTE26Ra1m9nvM%3Deds2RSSu7WSL-r2wKw%40mail.gmail.com
* Don't bother to attach column name lists to RowExprs of named types.Tom Lane2022-03-17
| | | | | | | | | If a RowExpr is marked as returning a named composite type, we aren't going to consult its colnames list; we'll use the attribute names shown for the type in pg_attribute. Hence, skip storing that list, to save a few nanoseconds when copying the expression tree around. Discussion: https://postgr.es/m/2950001.1638729947@sss.pgh.pa.us
* Revert applying column aliases to the output of whole-row Vars.Tom Lane2022-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit bf7ca1587, I had the bright idea that we could make the result of a whole-row Var (that is, foo.*) track any column aliases that had been applied to the FROM entry the Var refers to. However, that's not terribly logically consistent, because now the output of the Var is no longer of the named composite type that the Var claims to emit. bf7ca1587 tried to handle that by changing the output tuple values to be labeled with a blessed RECORD type, but that's really pretty disastrous: we can wind up storing such tuples onto disk, whereupon they're not readable by other sessions. The only practical fix I can see is to give up on what bf7ca1587 tried to do, and say that the column names of tuples produced by a whole-row Var are always those of the underlying named composite type, query aliases or no. While this introduces some inconsistencies, it removes others, so it's not that awful in the abstract. What *is* kind of awful is to make such a behavioral change in a back-patched bug fix. But corrupt data is worse, so back-patched it will be. (A workaround available to anyone who's unhappy about this is to introduce an extra level of sub-SELECT, so that the whole-row Var is referring to the sub-SELECT's output and not to a named table type. Then the Var is of type RECORD to begin with and there's no issue.) Per report from Miles Delahunty. The faulty commit dates to 9.5, so back-patch to all supported branches. Discussion: https://postgr.es/m/2950001.1638729947@sss.pgh.pa.us
* Refactor code for reading and writing relation map files.Robert Haas2022-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | Restructure things so that the functions which update the global variables shared_map and local_map are separate from the functions which just read and write relation map files without touching any global variables. In the new structure of things, write_relmap_file() writes a relmap file but no longer performs global variable updates. A symmetric function read_relmap_file() that just reads a file without changing any global variables is added, and load_relmap_file(), which does change the global variables, uses it as a subroutine. Because write_relmap_file() no longer updates shared_map and local_map, that logic is moved to perform_relmap_update(). However, no similar logic is added to relmap_redo() even though it also calls write_relmap_file(). That's because recovery must not rely on the contents of the relation map, and therefore there is no need to initialize it. In fact, doing so seems like a mistake, because we might then manage to rely on the in-memory map where we shouldn't. Patch by me, based on earlier work by Dilip Kumar. Reviewed by Ashutosh Sharma. Discussion: http://postgr.es/m/CA+TgmobQLgrt4AXsc0ru7aFFkzv=9fS-Q_yO69=k9WY67RCctg@mail.gmail.com
* Fix row filters with multiple publicationsTomas Vondra2022-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | When publishing changes through a artition root, we should use the row filter for the top-most ancestor. The relation may be added to multiple publications, using different ancestors, and 52e4f0cd47 handled this incorrectly. With c91f71b9dc we find the correct top-most ancestor, but the code tried to fetch the row filter from all publications, including those using a different ancestor etc. No row filter can be found for such publications, which was treated as replicating all rows. Similarly to c91f71b9dc, this seems to be a rare issue in practice. It requires multiple publications including the same partitioned relation, through different ancestors. Fixed by only passing publications containing the top-most ancestor to pgoutput_row_filter_init(), so that treating a missing row filter as replicating all rows is correct. Report and fix by me, test case by Hou zj. Reviews and improvements by Amit Kapila. Author: Tomas Vondra, Hou zj, Amit Kapila Reviewed-by: Amit Kapila, Hou zj Discussion: https://postgr.es/m/d26d24dd-2fab-3c48-0162-2b7f84a9c893%40enterprisedb.com
* Split ExecUpdate and ExecDelete into reusable piecesAlvaro Herrera2022-03-17
| | | | | | | | | | | | | | | | | | | | Create subroutines ExecUpdatePrologue / ExecUpdateAct / ExecUpdateEpilogue, and similar for ExecDelete. Introduce a new struct to be used internally in nodeModifyTable.c, dubbed ModifyTableContext, which contains all context information needed to perform these operations, as well as ExecInsert and others. This allows using a different schedule and a different way of evaluating the results of these operations, which can be exploited by a later commit introducing support for MERGE. It also makes ExecUpdate and ExecDelete proper shorter and (hopefully) simpler. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/202202271724.4z7xv3cf46kv@alvherre.pgsql
* Add option to use ICU as global locale providerPeter Eisentraut2022-03-17
| | | | | | | | | | | | | | | | | | This adds the option to use ICU as the default locale provider for either the whole cluster or a database. New options for initdb, createdb, and CREATE DATABASE are used to select this. Since some (legacy) code still uses the libc locale facilities directly, we still need to set the libc global locale settings even if ICU is otherwise selected. So pg_database now has three locale-related fields: the existing datcollate and datctype, which are always set, and a new daticulocale, which is only set if ICU is selected. A similar change is made in pg_collation for consistency, but in that case, only the libc-related fields or the ICU-related field is set, never both. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com
* Fix pg_tablespace_location() with in-place tablespacesMichael Paquier2022-03-17
| | | | | | | | | | | | | | | | | | | | | | | Using this system function with an in-place tablespace (created when allow_in_place_tablespaces is enabled by specifying an empty string as location) caused a failure when using readlink(), as the tablespace is, in this case, not a symbolic link in pg_tblspc/ but a directory. Rather than getting a failure, the commit changes pg_tablespace_location() so as a relative path to the data directory is returned for in-place tablespaces, to make a difference between tablespaces created when allow_in_place_tablespaces is enabled or not. Getting a path rather than an empty string that would match the CREATE TABLESPACE command in this case is more useful for tests that would like to rely on this function. While on it, a regression test is added for this case. This is simple to add in the main regression test suite thanks to regexp_replace() to mask the part of the tablespace location dependent on its OID. Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Thomas Munro Discussion: https://postgr.es/m/YiG1RleON1WBcLnX@paquier.xyz
* Fix publish_as_relid with multiple publicationsTomas Vondra2022-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 83fd4532a7 allowed publishing of changes via ancestors, for publications defined with publish_via_partition_root. But the way the ancestor was determined in get_rel_sync_entry() was incorrect, simply updating the same variable. So with multiple publications, replicating different ancestors, the outcome depended on the order of publications in the list - the value from the last loop was used, even if it wasn't the top-most ancestor. This is a probably rare situation, as in most cases publications do not overlap, so each partition has exactly one candidate ancestor to replicate as and there's no ambiguity. Fixed by tracking the "ancestor level" for each publication, and picking the top-most ancestor. Adds a test case, verifying the correct ancestor is used for publishing the changes and that this does not depend on order of publications in the list. Older releases have another bug in this loop - once all actions are replicated, the loop is terminated, on the assumption that inspecting additional publications is unecessary. But that misses the fact that those additional applications may replicate different ancestors. Fixed by removal of this break condition. We might still terminate the loop in some cases (e.g. when replicating all actions and the ancestor is the partition root). Backpatch to 13, where publish_via_partition_root was introduced. Initial report and fix by me, test added by Hou zj. Reviews and improvements by Amit Kapila. Author: Tomas Vondra, Hou zj, Amit Kapila Reviewed-by: Amit Kapila, Hou zj Discussion: https://postgr.es/m/d26d24dd-2fab-3c48-0162-2b7f84a9c893%40enterprisedb.com
* Suppress compiler warnings.Robert Haas2022-03-16
| | | | | | Michael Paquier Discussion: http://postgr.es/m/YjGvq4zPDT6j15go@paquier.xyz
* Fix race between DROP TABLESPACE and checkpointing.Thomas Munro2022-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commands like ALTER TABLE SET TABLESPACE may leave files for the next checkpoint to clean up. If such files are not removed by the time DROP TABLESPACE is called, we request a checkpoint so that they are deleted. However, there is presently a window before checkpoint start where new unlink requests won't be scheduled until the following checkpoint. This means that the checkpoint forced by DROP TABLESPACE might not remove the files we expect it to remove, and the following ERROR will be emitted: ERROR: tablespace "mytblspc" is not empty To fix, add a call to AbsorbSyncRequests() just before advancing the unlink cycle counter. This ensures that any unlink requests forwarded prior to checkpoint start (i.e., when ckpt_started is incremented) will be processed by the current checkpoint. Since AbsorbSyncRequests() performs memory allocations, it cannot be called within a critical section, so we also need to move SyncPreCheckpoint() to before CreateCheckPoint()'s critical section. This is an old bug, so back-patch to all supported versions. Author: Nathan Bossart <nathandbossart@gmail.com> Reported-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220215235845.GA2665318%40nathanxps13
* Fix waiting in RegisterSyncRequest().Thomas Munro2022-03-16
| | | | | | | | | | | | | | | | | If we run out of space in the checkpointer sync request queue (which is hopefully rare on real systems, but common with very small buffer pool), we wait for it to drain. While waiting, we should report that as a wait event so that users know what is going on, and also handle postmaster death, since otherwise the loop might never terminate if the checkpointer has exited. Back-patch to 12. Although the problem exists in earlier releases too, the code is structured differently before 12 so I haven't gone any further for now, in the absence of field complaints. Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de
* Wake up for latches in CheckpointWriteDelay().Thomas Munro2022-03-16
| | | | | | | | | | | | | | | | | | | | | The checkpointer shouldn't ignore its latch. Other backends may be waiting for it to drain the request queue. Hopefully real systems don't have a full queue often, but the condition is reached easily when shared_buffers is small. This involves defining a new wait event, which will appear in the pg_stat_activity view often due to spread checkpoints. Back-patch only to 14. Even though the problem exists in earlier branches too, it's hard to hit there. In 14 we stopped using signal handlers for latches on Linux, *BSD and macOS, which were previously hiding this problem by interrupting the sleep (though not reliably, as the signal could arrive before the sleep begins; precisely the problem latches address). Reported-by: Andres Freund <andres@anarazel.de> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de
* Silence LLVM 14 API deprecation warnings.Thomas Munro2022-03-16
| | | | | | | | | | | We are going to need to handle the upcoming opaque pointer API changes[1], possibly in time for LLVM 15, but in the meantime let's silence the warnings produced by LLVM 14. [1] https://llvm.org/docs/OpaquePointers.html Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA%2BhUKG%2Bp%3DfaBQR2PSAqWoWa%2B_tJdKPT0wjZPQe7XcDEttUCgdQ%40mail.gmail.com
* Remove accidentally-committed file.Robert Haas2022-03-15
|
* Allow extensions to add new backup targets.Robert Haas2022-03-15
| | | | | | | | | | | | Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc allowed for base backup targets, meaning that we could do something with the backup other than send it to the client, but all of those targets had to be baked in to the core code. This commit makes it possible for extensions to define additional backup targets. Patch by me, reviewed by Abhijit Menon-Sen. Discussion: http://postgr.es/m/CA+TgmoaqvdT-u3nt+_kkZ7bgDAyqDB0i-+XOMmr5JN2Rd37hxw@mail.gmail.com
* Change HAVE_LIBLZ4 and HAVE_LIBZSTD tests to USE_LZ4 and USE_ZSTD.Robert Haas2022-03-15
| | | | | | | | | | | These tests were added recently, but older code tests USE_LZ4 rathr than HAVE_LIBLZ4, so let's follow the established precedent. It also seems more consistent with the intent of the configure tests, since I think that the USE_* symbols are intended to correspond to what the user requested, and the HAVE_* symbols to what configure found while probing. Discussion: http://postgr.es/m/CA+Tgmoap+hTD2-QNPJLH4tffeFE8MX5+xkbFKMU3FKBy=ZSNKA@mail.gmail.com
* Fix compiler warning introduced in commit 705e20f855.Amit Kapila2022-03-15
| | | | | | | Reported-by: Nathan Bossart Author: Nathan Bossart Reviewed-by: Osumi Takamichi Discussion : https://postgr.es/m/20220314230424.GA1085716@nathanxps13
* Fix collection of typos in the code and the documentationMichael Paquier2022-03-15
| | | | | | | | Some words were duplicated while other places were grammatically incorrect, including one variable name in the code. Author: Otto Kekalainen, Justin Pryzby Discussion: https://postgr.es/m/7DDBEFC5-09B6-4325-B942-B563D1A24BDC@amazon.com
* Add more regression tests for pg_ls_dir()Michael Paquier2022-03-15
| | | | | | | | | | | | | | This system function was being triggered once in the main regression test suite to check its SRF configuration, and more in other test modules but nothing checked the behavior of the options missing_ok and include_dot_dirs. This commit adds some tests for both options, to avoid mistakes if this code is manipulated in the future. Extracted from a larger patch by the same author, with a few tweaks by me. Author: Justin Pryzby Discussion: https://postgr.es/m/20191227170220.GE12890@telsasoft.com
* Fix pg_basebackup with in-place tablespaces.Thomas Munro2022-03-15
| | | | | | | | | | | Previously, pg_basebackup from a cluster that contained an 'in-place' tablespace, as introduced by commit 7170f215, would produce a harmless warning on Unix and fail completely on Windows. Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/20220304.165449.1200020258723305904.horikyota.ntt%40gmail.com
* Support "of", "tzh", and "tzm" format codes.Robert Haas2022-03-14
| | | | | | | | | | | | The upper case versions "OF", "TZH", and "TZM" are already supported, and all other format codes that are supported in upper case are also supported in lower case, so we should support these as well for consistency. Nitin Jadhav, with a tiny cosmetic change by me. Reviewed by Suraj Kharage and David Zhang. Discussion: http://postgr.es/m/CAMm1aWZ-oZyKd75+8D=VJ0sAoSwtdXWLP-MAWD4D8R1Dgandzw@mail.gmail.com
* Optionally disable subscriptions on error.Amit Kapila2022-03-14
| | | | | | | | | | | | | | | | | | | | | | Logical replication apply workers for a subscription can easily get stuck in an infinite loop of attempting to apply a change, triggering an error (such as a constraint violation), exiting with the error written to the subscription server log, and restarting. To partially remedy the situation, this patch adds a new subscription option named 'disable_on_error'. To be consistent with old behavior, this option defaults to false. When true, both the tablesync worker and apply worker catch any errors thrown and disable the subscription in order to break the loop. The error is still also written in the logs. Once the subscription is disabled, users can either manually resolve the conflict/error or skip the conflicting transaction by using pg_replication_origin_advance() function. After resolving the conflict, users need to enable the subscription to allow apply process to proceed. Author: Osumi Takamichi and Mark Dilger Reviewed-by: Greg Nancarrow, Vignesh C, Amit Kapila, Wang wei, Tang Haiying, Peter Smith, Masahiko Sawada, Shi Yu Discussion : https://postgr.es/m/DB35438F-9356-4841-89A0-412709EBD3AB%40enterprisedb.com
* Fix bogus tab-completion queries.Tom Lane2022-03-13
| | | | | | | | | | | My (tgl's) thinko in commit 02b8048ba: I forgot that the first argument of COMPLETE_WITH_QUERY_PLUS is a format string, and hence failed to double a literal %. These two places seem to be the only ones that are wrong, though. Vignesh C Discussion: https://postgr.es/m/CALDaNm0hBO+tZqBWhBjTVxyET1GWANq5K9XpQ07atSxnFXbG7w@mail.gmail.com
* VACUUM VERBOSE: tweak scanned_pages logic.Peter Geoghegan2022-03-13
| | | | | | | | | | | | Commit 872770fd6c taught VACUUM VERBOSE and autovacuum logging to display the total number of pages scanned by VACUUM. This information was also displayed as a percentage of rel_pages in parenthesis, which makes it easy to spot trends over time and across tables. The instrumentation displayed "0 scanned (0.00% of total)" for totally empty tables. Tweak the instrumentation: have it show "0 scanned (100.00% of total)" for empty tables instead. This approach is clearer and more consistent.
* Force track_io_timing off in explain.sql to avoid failures when enabled.Andres Freund2022-03-12
| | | | Discussion: https://postgr.es/m/20201029231037.rkxo57ugnuchykpu@alap3.anarazel.de
* Set synchronous_commit=on in test_setup.sql.Andres Freund2022-03-12
| | | | | | | | | | | | | | | Starting in cc50080a82 create_index test fails when run with synchronous_commit=off. synchronous_commit=off delays when hint bits may be set. Some plans change depending on the number of all-visible pages, which in turn can be influenced by the delayed hint bits. Force synchronous_commit to `on` in test_setup.sql. Not very satisfying, but there's no obvious alternative. Reported-By: Aleksander Alekseev <aleksander@timescale.com> Author: Andres Freund <andres@anarazel.de> Author: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://www.postgresql.org/message-id/flat/CAJ7c6TPJNof1Q+vJsy3QebgbPgXdu2ErPvYkBdhD6_Ckv5EZRg@mail.gmail.com
* vacuumlazy.c: Standardize rel_pages terminology.Peter Geoghegan2022-03-12
| | | | | | | | | | | | | | | | | VACUUM's rel_pages field indicates the size of the target heap rel just after the table_relation_vacuum() operation began. There are specific expectations around how rel_pages can be related to other nearby state. In particular, the range of rel_pages must contain every tuple in the relation whose tuple headers might contain an XID < OldestXmin. Consistently refer to the field as rel_pages to make this clearer and more discoverable. This is follow-up work to commit 73f6ec3d from earlier today. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220311031351.sbge5m2bpvy2ttxg@alap3.anarazel.de
* vacuumlazy.c: document vistest and OldestXmin.Peter Geoghegan2022-03-12
| | | | | | | | | | | | | | | | | | | | | | | Explain the relationship between vacuumlazy.c's vistest and OldestXmin cutoffs. These closely related cutoffs are different in subtle but important ways. Also document a closely related rule: we must establish rel_pages _after_ OldestXmin to ensure that no XID < OldestXmin can be missed by lazy_scan_heap(). It's easier to explain these issues by initializing everything together, so consolidate initialization of vacrel state. Now almost every vacrel field is initialized by heap_vacuum_rel(). The only remaining exception is the dead_items array, which is still managed by lazy_scan_heap() due to interactions with how we initialize parallel VACUUM. Also move the process that updates pg_class entries for each index into heap_vacuum_rel(), and adjust related assertions. All pg_class updates now take place after lazy_scan_heap() returns, which seems clearer. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20211211045710.ljtuu4gfloh754rs@alap3.anarazel.de Discussion: https://postgr.es/m/CAH2-WznYsUxVT156rCQ+q=YD4S4=1M37hWvvHLz-H1pwSM8-Ew@mail.gmail.com
* Normalize heap_prepare_freeze_tuple argument name.Peter Geoghegan2022-03-11
| | | | | | We called the argument totally_frozen in its function prototype as well as in code comments, even though totally_frozen_p was used in the function definition. Standardize on totally_frozen.
* Bump XLOG_PAGE_MAGIC due to the addition of wal_compression=zstdMichael Paquier2022-03-12
| | | | | | | | | While on it, fix a thinko in the docs, introduced by the same commit. Oversights in e953732. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20220311214900.GN28503@telsasoft.com
* Add API of sorts for transition table handling in trigger.cAlvaro Herrera2022-03-11
| | | | | | | | | | Preparatory patch for further additions in this area, particularly to allow MERGE to have separate transition tables for each action. Author: Pavan Deolasee <pavan.deolasee@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/CABOikdNj+8HEJ5D8tu56mrPkjHVRrBb2_cdKWwpiYNcjXgDw8g@mail.gmail.com Discussion: https://postgr.es/m/20201231134736.GA25392@alvherre.pgsql
* Restore the previous semantics of get_constraint_index().Tom Lane2022-03-11
| | | | | | | | | | | | | | | | | | | | | | | | Commit 8b069ef5d changed this function to look at pg_constraint.conindid rather than searching pg_depend. That was a good performance improvement, but it failed to preserve the exact semantics. The old code would only return an index that was "owned by" (internally dependent on) the specified constraint, whereas the new code will also return indexes that are just referenced by foreign key constraints. This confuses ALTER TABLE, which was implicitly expecting the previous semantics, into failing with errors like ERROR: relation 146621 has multiple clustered indexes or ERROR: "pk_attbl" is not an index for table "atref" We can fix this without reverting the performance improvement by adding a contype check in get_constraint_index(). Another way could be to make ALTER TABLE check it, but I'm worried that extension code could also have subtle dependencies on the old semantics. Tom Lane and Japin Li, per bug #17409 from Holly Roberts. Back-patch to v14 where the error crept in. Discussion: https://postgr.es/m/17409-52871dda8b5741cb@postgresql.org
* pg_basebackup: Clean up some bogus file extension tests.Robert Haas2022-03-11
| | | | | | Justin Pryzby Discussion: http://postgr.es/m/20220311162911.GM28503@telsasoft.com
* pg_basebackup: Avoid unclean failure with server-compression and -D -.Robert Haas2022-03-11
| | | | | | | | | | | | | | | | Fail with a suitable error message instead. We can't inject the backup manifest into the output tarfile without decompressing it, and if we did that, we'd have to recompress the tarfile afterwards to produce the result the user is expecting. While we have enough infrastructure in pg_basebackup now to accomplish that whole series of steps without much additional code, it seems like excessively surprising behavior. The user probably did not select server-side compression with the idea that the client was going to end up decompressing it and then recompressing. Report from Justin Pryzby. Fix by me. Discussion: http://postgr.es/m/CA+Tgmob6Rnjz-Qv32h3yJn8nnUkLhrtQDAS4y5AtsgtorAFHRA@mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 20:40:13 +0000