aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Doc: Refer to line pointers as item identifiers.Peter Geoghegan2019-05-13
| | | | | | | | | | | An upcoming HEAD-only patch will standardize the terminology around ItemIdData variables/line pointers, ending the practice of referring to them as "item pointers". Make the "Database Page Layout" docs consistent with the new policy. The term "item identifier" is already used in the same section, so stick with that. Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com Backpatch: All supported branches.
* Fix logical replication's ideas about which type OIDs are built-in.Tom Lane2019-05-13
| | | | | | | | | | | | | | | | | | Only hand-assigned type OIDs should be presumed to match across different PG servers; those assigned during genbki.pl or during initdb are likely to change due to addition or removal of unrelated objects. This means that the cutoff should be FirstGenbkiObjectId (in HEAD) or FirstBootstrapObjectId (before that), not FirstNormalObjectId. Compare postgres_fdw's is_builtin() test. It's likely that this error has no observable consequence in a normally-functioning system, since ATM the only affected type OIDs are system catalog rowtypes and information_schema types, which would not typically be interesting for logical replication. But you could probably break it if you tried hard, so back-patch. Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
* Improve commentary about hack in is_publishable_class().Tom Lane2019-05-13
| | | | | | | | | The FirstNormalObjectId test here is a kluge that needs to go away, but the only substitute we can think of is to add a column to pg_class, which will take more work than can be handled right now. Add some commentary in the meanwhile. Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
* Don't leave behind junk nbtree pages during split.Peter Geoghegan2019-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8fa30f906be reduced the elevel of a number of "can't happen" _bt_split() errors from PANIC to ERROR. At the same time, the new right page buffer for the split could continue to be acquired well before the critical section. This was possible because it was relatively straightforward to make sure that _bt_split() could not throw an error, with a few specific exceptions. The exceptional cases were safe because they involved specific, well understood errors, making it possible to consistently zero the right page before actually raising an error using elog(). There was no danger of leaving around a junk page, provided _bt_split() stuck to this coding rule. Commit 8224de4f, which introduced INCLUDE indexes, added code to make _bt_split() truncate away non-key attributes. This happened at a point that broke the rule around zeroing the right page in _bt_split(). If truncation failed (perhaps due to palloc() failure), that would result in an errant right page buffer with junk contents. This could confuse VACUUM when it attempted to delete the page, and should be avoided on general principle. To fix, reorganize _bt_split() so that truncation occurs before the new right page buffer is even acquired. A junk page/buffer will not be left behind if _bt_nonkey_truncate()/_bt_truncate() raise an error. Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=VWMw@mail.gmail.com Backpatch: 11-, where INCLUDE indexes were introduced.
* Improve comment for att_isnull.Robert Haas2019-05-13
| | | | | | | | | | The comment implies that a 1 in the null bitmap indicates a null value, but actually a 0 in the null bitmap indicates a null value. Try to be more clear. Patch by me; proposed wording reviewed by Alvaro Herrera and Tom Lane. Discussion: http://postgr.es/m/CA+TgmobHOP8r6cG+UnsDFMrS30-m=jRrCBhgw-nFkn0k9QnFsg@mail.gmail.com
* Fix misuse of an integer as a bool.Tom Lane2019-05-13
| | | | | | | | | | | | | | | | | | | pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346526@postgresql.org
* postgres_fdw: Fix typo in comment.Etsuro Fujita2019-05-13
|
* doc: PG 12 release notes: normalize attribution namesBruce Momjian2019-05-12
| | | | | | Reported-by: David Rowley Discussion: https://postgr.es/m/CAKJS1f-ktEhmQ2zJQ1L1niuJ9KB8WPA-bE-AhGiFsSO6QASB_w@mail.gmail.com
* doc: adjust PG 12 release note sectionsBruce Momjian2019-05-12
| | | | Tighten section designations.
* docs: fix typo in mention of MSVCBruce Momjian2019-05-12
|
* Fix incorrect return value in JSON equality function for scalarsMichael Paquier2019-05-13
| | | | | | | | | | | | equalsJsonbScalarValue() uses a boolean as return type, however for one code path -1 gets returned, which is confusing. The origin of the confusion is visibly that this code got copy-pasted from compareJsonbScalarValue() since it has been introduced in d1d50bf. No backpatch, as this is only cosmetic. Author: Rikard Falkeborn Discussion: https://postgr.es/m/CADRDgG7mJnek6HNW13f+LF6V=6gag9PM+P7H5dnyWZAv49aBGg@mail.gmail.com
* Fix misoptimization of "{1,1}" quantifiers in regular expressions.Tom Lane2019-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bounded quantifier with m = n = 1 might be thought a no-op. But according to our documentation (which traces back to Henry Spencer's original man page) it still imposes greediness, or non-greediness in the case of the non-greedy variant "{1,1}?", on whatever it's attached to. This turns out not to work though, because parseqatom() optimizes away the m = n = 1 case without regard for whether it's supposed to change the greediness of the argument RE. We can fix this by just not applying the optimization when the greediness needs to change; the subsequent general cases handle it fine. The three cases in which we can still apply the optimization are (a) no quantifier, or quantifier does not impose a preference; (b) atom has no greediness property, implying it cannot match a variable amount of text anyway; or (c) quantifier's greediness is same as atom's. Note that in most cases where one of these applies, we'd have exited earlier in the "not a messy case" fast path. I think it's now only possible to get to the optimization when the atom involves capturing parentheses or a non-top-level backref. Back-patch to all supported branches. I'd ordinarily be hesitant to put a subtle behavioral change into back branches, but in this case it's very hard to see a reason why somebody would write "{1,1}?" unless they're trying to get the documented change-of-greediness behavior. Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net
* Fail pgwin32_message_to_UTF16() for SQL_ASCII messages.Noah Misch2019-05-12
| | | | | | | | | | | | The function had been interpreting SQL_ASCII messages as UTF8, throwing an error when they were invalid UTF8. The new behavior is consistent with pg_do_encoding_conversion(). This affects LOG_DESTINATION_STDERR and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to write() and ReportEventA(). On buildfarm member bowerbird, enabling log_connections caused an error whenever the role name was not valid UTF8. Back-patch to 9.4 (all supported versions). Discussion: https://postgr.es/m/20190512015615.GD1124997@rfd.leadboat.com
* Rearrange pgstat_bestart() to avoid failures within its critical section.Tom Lane2019-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We long ago decided to design the shared PgBackendStatus data structure to minimize the cost of writing status updates, which means that writers just have to increment the st_changecount field twice. That isn't hooked into any sort of resource management mechanism, which means that if something were to throw error between the two increments, the st_changecount field would be left odd indefinitely. That would cause readers to lock up. Now, since it's also a bad idea to leave the field odd for longer than absolutely necessary (because readers will spin while we have it set), the expectation was that we'd treat these segments like spinlock critical sections, with only short, more or less straight-line, code in them. That was fine as originally designed, but commit 9029f4b37 broke it by inserting a significant amount of non-straight-line code into pgstat_bestart(), code that is very capable of throwing errors, not to mention taking a significant amount of time during which readers will spin. We have a report from Neeraj Kumar of readers actually locking up, which I suspect was due to an encoding conversion error in X509_NAME_to_cstring, though conceivably it was just a garden-variety OOM failure. Subsequent commits have loaded even more dubious code into pgstat_bestart's critical section (and commit fc70a4b0d deserves some kind of booby prize for managing to miss the critical section entirely, although the negative consequences seem minimal given that the PgBackendStatus entry should be seen by readers as inactive at that point). The right way to fix this mess seems to be to compute all these values into a local copy of the process' PgBackendStatus struct, and then just copy the data back within the critical section proper. This plan can't be implemented completely cleanly because of the struct's heavy reliance on out-of-line strings, which we must initialize separately within the critical section. But still, the critical section is far smaller and safer than it was before. In hopes of forestalling future errors of the same ilk, rename the macros for st_changecount management to make it more apparent that the writer-side macros create a critical section. And to prevent the worst consequences if we nonetheless manage to mess it up anyway, adjust those macros so that they really are a critical section, ie they now bump CritSectionCount. That doesn't add much overhead, and it guarantees that if we do somehow throw an error while the counter is odd, it will lead to PANIC and a database restart to reset shared memory. Back-patch to 9.5 where the problem was introduced. In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach pgstat_read_current_status to copy st_gssstatus data from shared memory to local memory. Hence, subsequent use of that data within the transaction would potentially see changing data that it shouldn't see. Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com
* docs: remove second mention of btree max length reductionBruce Momjian2019-05-11
| | | | | | I already added that to the incompatibility section as a separate item. Reported-by: Peter Geoghegan
* doc: remove pg_config mention from PG 12 release notesBruce Momjian2019-05-11
| | | | | | Reported-by: Tom Lane Discussion: https://postgr.es/m/28209.1556556696@sss.pgh.pa.us
* docs: PG 12 release notes, mention that REINDEX could now failBruce Momjian2019-05-11
| | | | | | This is because of the new tid in the index entry. Reported-by: Peter Geoghegan
* docs: add links from the PG 12 release notes to the main docsBruce Momjian2019-05-11
|
* docs: adjust PG 12 floating point itemBruce Momjian2019-05-11
| | | | | | Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87r295hjur.fsf@news-spur.riddles.org.uk
* Honor TEMP_CONFIG in TAP suites.Noah Misch2019-05-11
| | | | | | | | | | | | The buildfarm client uses TEMP_CONFIG to implement its extra_config setting. Except for stats_temp_directory, extra_config now applies to TAP suites; extra_config values seen in the past month are compatible with this. Back-patch to 9.6, where PostgresNode was introduced, so the buildfarm can rely on it sooner. Reviewed by Andrew Dunstan and Tom Lane. Discussion: https://postgr.es/m/20181229021950.GA3302966@rfd.leadboat.com
* Fix error reporting in reindexdbMichael Paquier2019-05-11
| | | | | | | | | | | | | When failing to reindex a table or an index, reindexdb would generate an extra error message related to a database failure, which is misleading. Backpatch all the way down, as this has been introduced by 85e9a5a0. Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com Author: Julien Rouhaud Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael Paquier Backpatch-through: 9.4
* Fix editing error in floating-point docs.Andrew Gierth2019-05-11
| | | | My fault; the error was introduced in the Ryu patch.
* doc: add Heikki to PG 12 release note btree itemBruce Momjian2019-05-10
| | | | | | Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com
* doc: improve PG 12 item on partitioned tablesBruce Momjian2019-05-10
| | | | | | Reported-by: Amit Langote Discussion: https://postgr.es/m/5936b052-5d92-a2c9-75d2-0245fb2330b5@lab.ntt.co.jp
* doc: reorder attribution of PG 12 btree itemBruce Momjian2019-05-10
| | | | | | Reported-by: Alexander Korotkov Discussion: https://postgr.es/m/CAPpHfdvkM-PkyrK6LQitJUDmC_1kOCEtTuseoVhCT=ew0XJmGg@mail.gmail.com
* docs: properly attribute PG 12 rel item to James ColemanBruce Momjian2019-05-10
| | | | | | Reported-by: David Rowley Discussion: https://postgr.es/m/CAKJS1f-NDmeA_tb0oRFhrgf19xq3A9MeoyMcckY04Ct=_i0c2A@mail.gmail.com
* docs: PG 12 docs, clarify btree index changesBruce Momjian2019-05-10
| | | | | | Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WzkSYOM1GJVGtAbRW-OqymoCD=QWYG6ro+GaoOW-jPRuDQ@mail.gmail.com
* doc: PG 12 release note adjustmentBruce Momjian2019-05-10
| | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190510013449.GL3925@telsasoft.com
* Remove reindex_catalog test from test schedules.Andres Freund2019-05-10
| | | | | | | | As none of the approaches for avoiding the deadlock issues seem promising enough, and all the expected reindex related changes have been made, apply 60c2951e1bab7e to master as well. Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us
* Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.Tom Lane2019-05-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a very old race condition in our code to see whether a pre-existing shared memory segment is still in use by a conflicting postmaster: it's possible for the other postmaster to remove the segment in between our shmctl() and shmat() calls. It's a narrow window, and there's no risk unless both postmasters are using the same port number, but that's possible during parallelized "make check" tests. (Note that while the TAP tests take some pains to choose a randomized port number, pg_regress doesn't.) If it does happen, we treated that as an unexpected case and errored out. To fix, allow EINVAL to be treated as segment-not-present, and the same for EIDRM on Linux. AFAICS, the considerations here are basically identical to the checks for acceptable shmctl() failures, so I documented and coded it that way. While at it, adjust PGSharedMemoryAttach's API to remove its undocumented dependency on UsedShmemSegAddr in favor of passing the attach address explicitly. This makes it easier to be sure we're using a null shmaddr when probing for segment conflicts (thus avoiding questions about what EINVAL means). I don't think there was a bug there, but it required fragile assumptions about the state of UsedShmemSegAddr during PGSharedMemoryIsInUse. Commit c09850992 may have made this failure more probable by applying the conflicting-segment tests more often. Hence, back-patch to all supported branches, as that was. Discussion: https://postgr.es/m/22224.1557340366@sss.pgh.pa.us
* doc: add markup for PG 12 release note textBruce Momjian2019-05-09
| | | | I will add links to other parts of the docs later.
* doc: PG 12 wording improvmentsBruce Momjian2019-05-09
| | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190510001335.GJ3925@telsasoft.com
* Fix and improve description of locktag types in lock.hMichael Paquier2019-05-10
| | | | | | | | | | | | The description of the lock type for speculative insertions was incorrect, being copy-pasted from another one. As discussed, also move the description for all the fields of lock tag types from the structure listing lock tag types to the set of macros setting each LOCKTAG. Author: John Naylor Discussion: https://postgr.es/m/CACPNZCtA0-ybaC4fFfaDq_8p_TUOLvGxZH9Dm-=TMHZJarBa7Q@mail.gmail.com
* doc: more PG 12 wording adjustmentsBruce Momjian2019-05-09
| | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190510001959.GK3925@telsasoft.com
* doc: fix capitalization in PG 12 release notesBruce Momjian2019-05-09
| | | | | | Reported-by: Thomas Munro Discussion: https://postgr.es/m/CA+hUKGJpep8uSXoDtVF6iROCRKce-39HEhDPUaYFyMn0U5e9ug@mail.gmail.com
* doc: more PG 12 release note adjustmentsBruce Momjian2019-05-09
| | | | | | | | | This adds two more items that should have been included in the beginning. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com
* docs: update release notes with fixesBruce Momjian2019-05-09
| | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com
* Improve and fix some error handling for REINDEX INDEX/TABLE CONCURRENTLYMichael Paquier2019-05-10
| | | | | | | | | | | | | | | | | | | This improves the user experience when it comes to restrict several flavors of REINDEX CONCURRENTLY. First, for INDEX, remove a restriction on shared relations as we already check after catalog relations. Then, for TABLE, add a proper error message when attempting to run the command on system catalogs. The code path of CREATE INDEX CONCURRENTLY already complains about that, but if a REINDEX is issued then then the error generated is confusing. While on it, add more tests to check restrictions on catalog indexes and on toast table/index for catalogs. Some error messages are improved, with wording suggestion coming from Tom Lane. Reported-by: Tom Lane Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/23694.1556806002@sss.pgh.pa.us
* Repair issues with faulty generation of merge-append plans.Tom Lane2019-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | create_merge_append_plan failed to honor the CP_EXACT_TLIST flag: it would generate the expected targetlist but then it felt free to add resjunk sort targets to it. This demonstrably leads to assertion failures in v11 and HEAD, and it's probably just accidental that we don't see the same in older branches. I've not looked into whether there would be any real-world consequences in non-assert builds. In HEAD, create_append_plan has sprouted the same problem, so fix that too (although we do not have any test cases that seem able to reach that bug). This is an oversight in commit 3fc6e2d7f which invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that came in. convert_subquery_pathkeys would create pathkeys for subquery output values if they match any EquivalenceClass known in the outer query and are available in the subquery's syntactic targetlist. However, the second part of that condition is wrong, because such values might not appear in the subquery relation's reltarget list, which would mean that they couldn't be accessed above the level of the subquery scan. We must check that they appear in the reltarget list, instead. This can lead to dropping knowledge about the subquery's sort ordering, but I believe it's okay, because any sort key that the outer query actually has any interest in would appear in the reltarget list. This second issue is of very long standing, but right now there's no evidence that it causes observable problems before 9.6, so I refrained from back-patching further than that. We can revisit that choice if somebody finds a way to make it cause problems in older branches. (Developing useful test cases for these issues is really problematic; fixing convert_subquery_pathkeys removes the only known way to exhibit the create_merge_append_plan bug, and neither of the test cases added by this patch causes a problem in all branches, even when considering the issues separately.) The second issue explains bug #15795 from Suresh Kumar R ("could not find pathkey item to sort" with nested DISTINCT queries). I stumbled across the first issue while investigating that. Discussion: https://postgr.es/m/15795-fadb56c8e44ee73c@postgresql.org
* doc: update PG 12 release notes, v2Bruce Momjian2019-05-09
| | | | | | | | Adjustments requested by reviewers. Reported-by: Amit Kapila, Thomas Munro, Andrew Gierth, Amit Langote, Oleg Bartunov, Michael Paquier, Alvaro Herrera, Tatsuo Ishii Discussion: https://postgr.es/m/20190506233029.ozwged67i7s4qd6c@momjian.us
* Doc: Update FDW documentation about GetForeignUpperPaths().Etsuro Fujita2019-05-09
| | | | | | | | | | In commit d50d172e51, which added support for LIMIT/OFFSET pushdown in postgres_fdw, a new struct was introduced as the extra parameter of GetForeignUpperPaths() set for UPPERREL_FINAL, but I forgot to update the documentation to mention that. Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK17uSXQDe31oRb-z1nYyT6vVzkstZkA3_Wbq38U92b9BmQ%40mail.gmail.com
* postgres_fdw: Fix cost estimation for aggregate pushdown.Etsuro Fujita2019-05-09
| | | | | | | | | | | | | | | | | In commit 7012b132d0, which added support for aggregate pushdown in postgres_fdw, the expense of evaluating the final scan/join target computed by make_group_input_target() was not accounted for at all in costing aggregate pushdown paths with local statistics. The right fix for this would be to have a separate upper stage to adjust the final scan/join relation (see comments for apply_scanjoin_target_to_paths()); but for now, fix by adding the tlist eval cost when costing aggregate pushdown paths with local statistics. Apply this to HEAD only to avoid destabilizing existing plan choices. Author: Etsuro Fujita Reviewed-By: Antonin Houska Discussion: https://postgr.es/m/5C66A056.60007%40lab.ntt.co.jp
* Fix SxactGlobalXmin tracking.Thomas Munro2019-05-09
| | | | | | | | | | | | | | | | Commit bb16aba50 broke the code that maintains SxactGlobalXmin. It could get stuck when a well-timed READ ONLY transaction runs. If SxactGlobalXmin stops advancing, transactions on the FinishedSerializableTransactions queue are never cleaned up, so resources are effectively leaked. Revert that hunk of the commit. Also revert another similar hunk that was probably harmless, but unnecessary and unjustified, relating to the DOOMED flag in case of RO_SAFE early release. Author: Thomas Munro Reported-by: Tom Lane Discussion: https://postgr.es/m/16170.1557251214%40sss.pgh.pa.us
* pg_controldata: Add common gettext flagsPeter Eisentraut2019-05-09
| | | | | So it picks up strings in pg_log_* calls. This was forgotten when it was added to all other relevant subdirectories.
* Fix grammar in error messagePeter Eisentraut2019-05-09
|
* Clean up the behavior and API of catalog.c's is-catalog-relation tests.Tom Lane2019-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The right way for IsCatalogRelation/Class to behave is to return true for OIDs less than FirstBootstrapObjectId (not FirstNormalObjectId), without any of the ad-hoc fooling around with schema membership. The previous code was wrong because (1) it claimed that information_schema tables were not catalog relations but their toast tables were, which is silly; and (2) if you dropped and recreated information_schema, which is a supported operation, the behavior changed. That's even sillier. With this definition, "catalog relations" are exactly the ones traceable to the postgres.bki data, which seems like what we want. With this simplification, we don't actually need access to the pg_class tuple to identify a catalog relation; we only need its OID. Hence, replace IsCatalogClass with "IsCatalogRelationOid(oid)". But keep IsCatalogRelation as a convenience function. This allows fixing some arguably-wrong semantics in contrib/sepgsql and ReindexRelationConcurrently, which were using an IsSystemNamespace test where what they really should be using is IsCatalogRelationOid. The previous coding failed to protect toast tables of system catalogs, and also was not on board with the general principle that user-created tables do not become catalogs just by virtue of being renamed into pg_catalog. We can also get rid of a messy hack in ReindexMultipleTables. While we're at it, also rename IsSystemNamespace to IsCatalogNamespace, because the previous name invited confusion with the more expansive semantics used by IsSystemRelation/Class. Also improve the comments in catalog.c. There are a few remaining places in replication-related code that are special-casing OIDs below FirstNormalObjectId. I'm inclined to think those are wrong too, and if there should be any special case it should just extend to FirstBootstrapObjectId. But first we need to debate whether a FOR ALL TABLES publication should include information_schema. Discussion: https://postgr.es/m/21697.1557092753@sss.pgh.pa.us Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
* Fix error status of vacuumdb when multiple jobs are usedMichael Paquier2019-05-09
| | | | | | | | | | | When running a batch of VACUUM or ANALYZE commands on a given database, there were cases where it is possible to have vacuumdb not report an error where it actually should, leading to incorrect status results. Author: Julien Rouhaud Reviewed-by: Amit Kapila, Michael Paquier Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com Backpatch-through: 9.5
* Remove obsolete nbtree split REDO routine comment.Peter Geoghegan2019-05-08
| | | | | | | | | Commit dd299df8189, which added suffix truncation to nbtree, simplified the WAL record format used by page splits. It became necessary to explicitly WAL-log the new high key for the left half of a split in all cases, which relieved the REDO routine from having to reconstruct a new high key for the left page by copying the first item from the right page. Remove a comment that referred to the previous practice.
* Fix error messagesAlvaro Herrera2019-05-08
| | | | | | | | | | Some messages related to foreign servers were reporting the server name without quotes, or not at all; our style is to have all names be quoted, and the server name already appears quoted in a few other messages, so just add quotes and make them all consistent. Remove an extra "s" in other messages (typos introduced by myself in f56f8f8da6af).
* Fix documentation for the privileges required for replication functions.Fujii Masao2019-05-09
| | | | | | | | | | | | | | | | Previously it's documented that use of replication functions is restricted to superusers. This is true for the functions which use replication origin, but not for pg_logicl_emit_message() and functions which use replication slot. For example, not only superusers but also users with REPLICATION privilege is allowed to use the functions for replication slot. This commit fixes the documentation for the privileges required for those replication functions. Back-patch to 9.4 (all supported versions). Author: Matsumura Ryo Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 12:16:22 +0000