aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Use the AddFile function consistently in MSVC build scriptsDavid Rowley2021-07-28
| | | | | | | | We seem to be using a mix of manually adding to the 'files' hash and calling the Addfile() method. Let's just consistently use AddFile(). Reviewed-by: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/CAApHDvpo6g5csCTjc_0C7DMvgFPomVb0Rh-AcW5afd=Ya=LRuw@mail.gmail.com
* Doc: Clarify lock levels taken during ATTACH PARTITIONDavid Rowley2021-07-28
| | | | | | | | | | | | | | | | | It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com Backpatch-through: 12
* Clarify some comments making use of leetspeak term "up2date"Michael Paquier2021-07-28
| | | | | | | | Most of these are new, as of a8fd13c, and "up-to-date" is much easier to parse for the average reader. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+PtHbHvgOjs_R9LyDF21j-Wn8SxoTtWMQNP2ifXN6t2cSg@mail.gmail.com
* Add support for SET ACCESS METHOD in ALTER TABLEMichael Paquier2021-07-28
| | | | | | | | | | | | | | | | The logic used to support a change of access method for a table is similar to changes for tablespace or relation persistence, requiring a table rewrite with an exclusive lock of the relation changed. Table rewrites done in ALTER TABLE already go through the table AM layer when scanning tuples from the old relation and inserting them into the new one, making this implementation straight-forward. Note that partitioned tables are not supported as these have no access methods defined. Author: Justin Pryzby, Jeff Davis Reviewed-by: Michael Paquier, Vignesh C Discussion: https://postgr.es/m/20210228222530.GD20769@telsasoft.com
* Remove seemingly unneeded include directory in MSVC scriptsDavid Rowley2021-07-28
| | | | | | | | | | | | | | | | This appears to have been added way back in ee3b4188a but it's a little unclear why the change made in that commit is even needed given that 320c7eb8c, dated 18 months earlier, added code to copy fmgroids.h to src/include/utils. amcheck seems to get away without adding the additional include directory, so perhaps dblink can get away with it too. This builds ok in my VS2017 environment, but the buildfarm may serve as a reminder about why ee3b4188a was required. There's only one way to find out for sure. Discussion: https://postgr.es/m/CAApHDvpo6g5csCTjc_0C7DMvgFPomVb0Rh-AcW5afd=Ya=LRuw@mail.gmail.com
* Set pg_setting.pending_restart when pertinent config lines are removedAlvaro Herrera2021-07-27
| | | | | | | | | | | | | | | | | This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql
* Fix bugs in polymorphic-argument resolution for multiranges.Tom Lane2021-07-27
| | | | | | | | | | | | | | We failed to deal with an UNKNOWN-type input for anycompatiblemultirange; that should throw an error indicating that we don't know how to resolve the multirange type. We also failed to infer the type of an anycompatiblerange output from an anycompatiblemultirange input or vice versa. Per bug #17066 from Alexander Lakhin. Back-patch to v14 where multiranges were added. Discussion: https://postgr.es/m/17066-16a37f6223a8470b@postgresql.org
* Stabilize output of new regression test.Tom Lane2021-07-27
| | | | | | | | | Commit 48c5c9068 failed to allow for buildfarm animals that force jit = on. I'm surprised that this hasn't come up elsewhere in explain.sql, so turn it off for that whole test script not just the one new test case. Per buildfarm.
* Avoid using ambiguous word "non-negative" in error messages.Fujii Masao2021-07-28
| | | | | | | | | | | | | | | | | | | | | | The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com
* In event triggers, use "pg_temp" only for our own temp schema.Tom Lane2021-07-27
| | | | | | | | | | | | | | pg_event_trigger_ddl_commands used "pg_temp" to refer to any temp schema, not only that of the current backend. This seems like overreach. It's somewhat unlikely that DDL commands would refer to temp objects of other sessions to begin with, but if they do, "pg_temp" would be a most misleading way to display the action. While this seems like a bug, it's not quite out of the realm of possibility that somebody out there is expecting the current behavior. Hence, fix in HEAD, but don't back-patch. Discussion: https://postgr.es/m/CAAJ_b97W=QaGmag9AhWNbmx3uEYsNkXWL+OVW1_E1D3BtgWvtw@mail.gmail.com
* Use the "pg_temp" schema alias in EXPLAIN and related output.Tom Lane2021-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch causes EXPLAIN output to refer to objects that are in the current session's temp schema with the "pg_temp" schema alias rather than that schema's actual name. This is useful for our own testing purposes since it will stabilize EXPLAIN VERBOSE output for such cases, allowing us to use that in regression tests. It should be less confusing for end users too. Since ruleutils.c needs to change behavior for this, the change also leaks into a few other users of ruleutils.c, for example pg_get_viewdef(). AFAICS that won't cause any problems. We did find that aggressively trying to change this behavior across-the-board would cause issues, but as long as "pg_temp" only appears within generated SQL text, I think it'll be fine. Along the way, make get_namespace_name_or_temp conform to the same API as get_namespace_name, ie that it returns a palloc'd string or NULL. The current behavior hasn't caused any bugs since no callers attempt to pfree the result, but if it gets more widespread usage that could become a problem. Amul Sul, reviewed and extended by me Discussion: https://postgr.es/m/CAAJ_b97W=QaGmag9AhWNbmx3uEYsNkXWL+OVW1_E1D3BtgWvtw@mail.gmail.com
* Disable command echo in pg_upgrade-created windows scriptsAndrew Dunstan2021-07-27
| | | | | | This makes them more like the Unix equivalents. Discussion: https://postgr.es/m/73deed30-3363-44e9-48a5-98aa66a8a00f@dunslane.net
* doc: for various substring funcs, document if only first matchBruce Momjian2021-07-26
| | | | | | | | Reported-by: troy@frericks.us Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org Backpatch-through: 13
* pg_resetxlog: add option to set oldest xid & use by pg_upgradeBruce Momjian2021-07-26
| | | | | | | | | | | | | | | | | | Add pg_resetxlog -u option to set the oldest xid in pg_control. Previously -x set this value be -2 billion less than the -x value. However, this causes the server to immediately scan all relation's relfrozenxid so it can advance pg_control's oldest xid to be inside the autovacuum_freeze_max_age range, which is inefficient and might disrupt diagnostic recovery. pg_upgrade will use this option to better create the new cluster to match the old cluster. Reported-by: Jason Harvey, Floris Van Nee Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com Author: Bertrand Drouvot Backpatch-through: 9.6
* Simplify matching pattern check in TAP tests of pg_receivewalMichael Paquier2021-07-27
| | | | | | | | | | A check in the ZLIB portion of the test to match the name of a non-compressed partial segment with a completed compressed segment was using m//, while a simple equality check is enough. This makes the test a bit stricter without impacting its coverage. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20210726.174622.826565852378770261.horikyota.ntt@gmail.com
* Skip trailing whitespaces when parsing integer optionsMichael Paquier2021-07-27
| | | | | | | | | | strtoint(), via strtol(), would skip leading whitespaces but the same rule was not applied for trailing whitespaces, leading to an inconsistent behavior. Some tests are changed to cover more this area. Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/YP5Pv0d13Ct+03ve@paquier.xyz
* Remove newly added useless assertion checkAlvaro Herrera2021-07-26
| | | | | | | | | | | Coverity complained that my commit 80ba4bb38353 added a dubious coding for a consistency check that there isn't more than one row for a certain tgrelid/tgparentid combination. But we don't check for that explicitly anywhere else, and if we were to do it, it should be a full shouldn't-happen elog not just an assert. It doesn't seem that this is very important anyway, so remove it. Discussion: https://postgr.es/m/1337562.1627224583@sss.pgh.pa.us
* psql \dX: check schema when listing statistics objectsTomas Vondra2021-07-26
| | | | | | | | | | | | | | | | | Commit ad600bba04 added psql command \dX listing extended statistics objects, but it failed to consider search_path when selecting the elements so some of the returned elements might be invisible. The visibility was already considered for tab completion (added by commit d99d58cdc8), so adding it to the query is fairly simple. Reported and fix by Justin Pryzby, regression tests by me. Backpatch to PostgreSQL 14, where \dX was introduced. Batchpatch-through: 14 Author: Justin Pryzby Reviewed-by: Tatsuro Yamada Discussion: https://postgr.es/m/c027a541-5856-75a5-0868-341301e1624b%40nttcom.co.jp_1
* Allow numeric scale to be negative or greater than precision.Dean Rasheed2021-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, when specifying NUMERIC(precision, scale), the scale had to be in the range [0, precision], which was per SQL spec. This commit extends the range of allowed scales to [-1000, 1000], independent of the precision (whose valid range remains [1, 1000]). A negative scale implies rounding before the decimal point. For example, a column might be declared with a scale of -3 to round values to the nearest thousand. Note that the display scale remains non-negative, so in this case the display scale will be zero, and all digits before the decimal point will be displayed. A scale greater than the precision supports fractional values with zeros immediately after the decimal point. Take the opportunity to tidy up the code that packs, unpacks and validates the contents of a typmod integer, encapsulating it in a small set of new inline functions. Bump the catversion because the allowed contents of atttypmod have changed for numeric columns. This isn't a change that requires a re-initdb, but negative scale values in the typmod would confuse old backends. Dean Rasheed, with additional improvements by Tom Lane. Reviewed by Tom Lane. Discussion: https://postgr.es/m/CAEZATCWdNLgpKihmURF8nfofP0RFtAKJ7ktY6GcZOPnMfUoRqA@mail.gmail.com
* doc: Fix command example to run regression tests with PGOPTIONSMichael Paquier2021-07-26
| | | | | | | | | | | | | The documentation mentioned the use of log_checkpoints, that cannot be used in this context. This commit replaces log_checkpoints with force_parallel_mode, a developer option useful to perform checks related to parallelism. Oversight in 854434c. Author: Haiying Tang Discussion: https://postgr.es/m/OS0PR01MB6113954B883ACEB2DDC973F2FBE59@OS0PR01MB6113.jpnprd01.prod.outlook.com Backpatch-through: 14
* Harden pg_stat_statements tests against CLOBBER_CACHE_ALWAYS.Tom Lane2021-07-25
| | | | | | | | Turns out the buildfarm hasn't been testing this, which will soon change. Julien Rouhaud, per report from me Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us
* Fix incorrect comment for get_agg_clause_costsDavid Rowley2021-07-26
| | | | | | | | | | | | | | | | Adjust the header comment in get_agg_clause_costs so that it matches what the function currently does. No recursive searching has been done ever since 0a2bc5d61. It also does not determine the aggtranstype like the comment claimed. That's all done in preprocess_aggref(). preprocess_aggref also now determines the numOrderedAggs, so remove the mention that get_agg_clause_costs also calculates "counts". Normally, since this is just an adjustment of a comment it might not be worth back-patching, but since this code is new to PG14 and that version is still in beta, then it seems worth having the comments match. Discussion: https://postgr.es/m/CAApHDvrrGrTJFPELrjx0CnDtz9B7Jy2XYW3Z2BKifAWLSaJYwQ@mail.gmail.com Backpatch-though: 14
* Fix a couple of memory leaks in src/bin/pg_basebackup/Michael Paquier2021-07-26
| | | | | | | | | | These have been introduced by 7fbe0c8, and could happen for pg_basebackup and pg_receivewal. Per report from Coverity for the ones in walmethods.c, I have spotted the ones in receivelog.c after more review. Backpatch-through: 10
* Get rid of artificial restriction on hash table sizes on Windows.Tom Lane2021-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The point of introducing the hash_mem_multiplier GUC was to let users reproduce the old behavior of hash aggregation, i.e. that it could use more than work_mem at need. However, the implementation failed to get the job done on Win64, where work_mem is clamped to 2GB to protect various places that calculate memory sizes using "long int". As written, the same clamp was applied to hash_mem. This resulted in severe performance regressions for queries requiring a bit more than 2GB for hash aggregation, as they now spill to disk and there's no way to stop that. Getting rid of the work_mem restriction seems like a good idea, but it's a big job and could not conceivably be back-patched. However, there's only a fairly small number of places that are concerned with the hash_mem value, and it turns out to be possible to remove the restriction there without too much code churn or any ABI breaks. So, let's do that for now to fix the regression, and leave the larger task for another day. This patch does introduce a bit more infrastructure that should help with the larger task, namely pg_bitutils.h support for working with size_t values. Per gripe from Laurent Hasson. Back-patch to v13 where the behavior change came in. Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com
* Deduplicate choice of horizon for a relation procarray.c.Andres Freund2021-07-24
| | | | | | | | | | | | | | | | 5a1e1d83022 was a minimal bug fix for dc7420c2c92. To avoid future bugs of that kind, deduplicate the choice of a relation's horizon into a new helper, GlobalVisHorizonKindForRel(). As the code in question was only introduced in dc7420c2c92 it seems worth backpatching this change as well, otherwise 14 will look different from all other branches. A different approach to this was suggested by Matthias van de Meent. Author: Andres Freund Discussion: https://postgr.es/m/20210621122919.2qhu3pfugxxp3cji@alap3.anarazel.de Backpatch: 14, like 5a1e1d83022
* Fix check for conflicting session- vs transaction-level locks.Tom Lane2021-07-24
| | | | | | | | | | | | | | | | | | | | | | | We have an implementation restriction that PREPARE TRANSACTION can't handle cases where both session-lifespan and transaction-lifespan locks are held on the same lockable object. (That's because we'd otherwise need to acquire a new PROCLOCK entry during post-prepare cleanup, which is an operation that might fail. The situation can only arise with odd usages of advisory locks, so removing the restriction is probably not worth the amount of effort it would take.) AtPrepare_Locks attempted to enforce this, but its logic was many bricks shy of a load, because it only detected cases where the session and transaction locks had the same lockmode. Locks of different modes on the same object would lead to the rather unhelpful message "PANIC: we seem to have dropped a bit somewhere". To fix, build a transient hashtable with one entry per locktag, not one per locktag + mode, and use that to detect conflicts. Per bug #17122 from Alexander Pyhalov. This bug is ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org
* Make printf("%s", NULL) print "(null)" instead of crashing.Tom Lane2021-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We previously took a hard-line attitude that callers should never print a null string pointer, and doing so is worthy of an assertion failure or crash. However, we've long since flushed out any easy-to-find bugs of that nature. What remains is a lot of code that perhaps could fail that way in hard-to-reach corner cases. For example, in something as simple as ereport(ERROR, (errcode(ERRCODE_UNDEFINED_OBJECT), errmsg("constraint \"%s\" for table \"%s\" does not exist", conname, get_rel_name(relid)))); one must wonder whether it's completely guaranteed that get_rel_name cannot return NULL in this context. If such a situation did occur, the existing policy converts what might be a pretty minor bug into a server crash condition. This is not good for robustness. Hence, let's follow the lead of glibc and print "(null)" instead of failing. We should, of course, still consider it a bug if that behavior is reachable in ordinary use; but crashing seems less desirable than not crashing. This fix works across-the-board in v12 and up, where we always use src/port/snprintf.c. Before that, on most platforms we're at the mercy of the local libc, but it appears that Solaris 10 is the only supported platform where we'd still get a crash. Most other platforms such as *BSD, macOS, and Solaris 11 have adopted glibc's behavior at some point. (AIX and HPUX just print "" not "(null)", but that's close enough.) I've not checked what Windows' native printf would do, but it doesn't matter because we've long used snprintf.c on that platform. In v12 and up, also const-ify related code so that we're not casting away const on the constant string. This is just neatnik-ism, since next to no compilers will warn about that. Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
* Remove configure-time thread safety checking (thread_test.c).Tom Lane2021-07-24
| | | | | | | | | | | | | | This testing was useful when it was written, nigh twenty years ago, but it seems fairly pointless for any platform built in the last dozen or more years. (Compare also the comments at 8a2121185.) Also we now have reports that the test program itself fails under ThreadSanitizer. Rather than invest effort in fixing it, let's just drop it, and assume that the few people who still care already know they need to use --disable-thread-safety. Back-patch into v14, for consistency with 8a2121185. Discussion: https://postgr.es/m/CADhDkKzPSiNvA3Hyq+wSR_icuPmazG0cFe=YnC3U-CFcYLc8Xw@mail.gmail.com
* Fix failure of some headers to compile "standalone".Tom Lane2021-07-24
| | | | | | | | Recently-added references to ParseState weren't covered by #include references, creating unwanted ordering dependencies for users of these headers. Oversight in commit 2bfb50b3d. Per headerscheck/cpluspluscheck.
* Add missing header declarations for pg_basebackup and pg_{dump,restore}Michael Paquier2021-07-24
| | | | | | | | This fixes two compilation failures caused by 6f164e6. Interesting to see that missing <limits.h> dies not fail in Linux or even Windows. On MacOS, it fails, though. Per various buildfarm members.
* Unify parsing logic for command-line integer optionsMichael Paquier2021-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the integer options for command-line binaries now make use of a single routine able to do the job, fixing issues with the detection of sloppy values caused for example by the use of atoi(), that fails on strings beginning with numerical characters with junk trailing characters. This commit cuts down the number of strings requiring translation by 26 per my count, switching the code to have two error types for invalid and out-of-range values instead. Much more could be done here, with float or even int64 options, but int32 was the most appealing case as it is possible to rely on strtol() to do the job reliably. Note that there are some exceptions for now, like pg_ctl or pg_upgrade that use their own logging logic. A couple of negative TAP tests required some adjustments for the new errors generated. pg_dump and pg_restore tracked the maximum number of parallel jobs within the option parsing. The code is refactored a bit to track that in the code dedicated to parallelism instead. Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: David Rowley, Álvaro Herrera Discussion: https://postgr.es/m/CALj2ACXqdG9WhqVoJ9zYf-iZt7sgK7Szv5USs=he6NnWQ2ofTA@mail.gmail.com
* Make new test immune to collationAlvaro Herrera2021-07-23
| | | | | | | | Animals running in Czech locale failed. I could try to find table names that don't have this problem, but it seems simpler to just use the C locale. Per buildfarm
* Make ALTER TRIGGER RENAME consistent for partitioned tablesAlvaro Herrera2021-07-22
| | | | | | | | | | | | | | | | Renaming triggers on partitioned tables had two problems: first, it did not recurse to renaming the triggers on the partitions; and second, it failed to prohibit renaming clone triggers. Having triggers with different names in partitions is pointless, and furthermore pg_dump would not preserve names for partitions anyway. Not backpatched -- making the ALTER TRIGGER throw an error in stable versions might cause problems for existing scripts. Co-authored-by: Arne Roland <A.Roland@index.de> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/d0fd7040c2fb4de1a111b9d9ccc456b8@index.de
* Rework installation instructions againAlvaro Herrera2021-07-22
| | | | | | | | | | | | | Dept. of second thoughts: the new verbiage added in commit aaec237b1a2f is targeted at the wrong audience. Remove the bits about git and talk about how to get tarballs only. People looking for the git repo can look in the appendix. That'll need to be expanded, but this commit doesn't do that. In passing, fix a couple of typos that snuck in with the previous commit. Discussion: https://postgr.es/m/713760.1626891263@sss.pgh.pa.us
* Fix division by zero error in date_binJohn Naylor2021-07-22
| | | | | | Bauyrzhan Sakhariyev, via Github Backpatch to v14
* Fix typo in commentPeter Eisentraut2021-07-22
| | | | | Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/20210716.170209.175434392011070182.horikyota.ntt%40gmail.com
* Disable TAP tests of pg_receivewal for ZLIB on WindowsMichael Paquier2021-07-22
| | | | | | | | | | | | | | | | This reverts commit 91d395f, to avoid running those tests on Windows. The tests are globally stable across all buildfarm members, except fairywren (crash of pg_receivewal) and bowerdird (SIGBREAK preventing the buildfarm run to complete). Those errors are rather strange, as other hosts with very similar characteristics are able to run those tests without breaking a sweat. For now, disable those tests on Windows to turn back the buildfarm to green. Per discussion with Andrew Dunstan. Discussion: https://postgr.es/m/9040d5ed-6462-66a4-07ac-2923785ae563@dunslane.net
* jit: Don't inline functions that access thread-locals.Thomas Munro2021-07-22
| | | | | | | | | | | | Code inlined by LLVM can crash or fail with "Relocation type not implemented yet!" if it tries to access thread local variables. Don't inline such code. Back-patch to 11, where LLVM arrived. Bug #16696. Author: Dmitry Marakasov <amdmi3@amdmi3.ru> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org
* Make nodeSort.c use Datum sorts for single column sortsDavid Rowley2021-07-22
| | | | | | | | | | | | | | | Datum sorts can be significantly faster than tuple sorts, especially when the data type being sorted is a pass-by-value type. Something in the region of 50-70% performance improvements appear to be possible. Just in case there's any confusion; the Datum sort is only used when the targetlist of the Sort node contains a single column, not when there's a single column in the sort key and multiple items in the target list. Author: Ronan Dunklau Reviewed-by: James Coleman, David Rowley, Ranier Vilela, Hou Zhijie Tested-by: John Naylor Discussion: https://postgr.es/m/3177670.itZtoPt7T5@aivenronan
* Doc: improve documentation about exponentiation operator.Tom Lane2021-07-21
| | | | | | | | | | Now that we're not having to wedge this into the straitjacket of the old operator table format, we can add another example to clarify the point about left-to-right associativity. Per suggestion from mdione at grulic.org.ar. https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org
* Improve installation instructions a bitAlvaro Herrera2021-07-21
| | | | | Reported-by: Daniel Westermann Discussion: https://postgr.es/m/GV0P278MB04835AAEACF894617574EB6BD25A9@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM
* Document "B" and "us" as accepted units in postgres.conf.sampleJohn Naylor2021-07-21
| | | | | | | | | | | | | | In postgresql.conf, memory and file size GUCs can be specified with "B" (bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us" (microseconds) as of caf626b2c. Update postgres.conf.sample to reflect that fact. Pavel Luzanov Backpatch to v12, which is the earliest version that allows both of these units. A separate commit will document the "B" case for v11. Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru
* Add missing check of noError parameter in euc_tw_and_big5.cJohn Naylor2021-07-21
| | | | | | | | | | Oversight in ea1b99a66 Yukun Wang Backpatch to v14 where this parameter was introduced Discussion: https://www.postgresql.org/message-id/flat/OS0PR01MB6003FCEFF0201EF21685FD33B4E39%40OS0PR01MB6003.jpnprd01.prod.outlook.com
* Add missing enum tags in enums used in nodesPeter Eisentraut2021-07-21
| | | | Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
* Rename some node support functions for consistencyPeter Eisentraut2021-07-21
| | | | | | | Some node function names didn't match their node type names exactly. Fix those for consistency. Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
* Rename argument of _outValue()Peter Eisentraut2021-07-21
| | | | | | Rename from value to node, for consistency with similar functions. Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
* Rename NodeTag of ExprStatePeter Eisentraut2021-07-21
| | | | | | Rename from tag to type, for consistency with all other node structs. Discussion: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
* More improvements of error messages about mismatching relkindPeter Eisentraut2021-07-21
| | | | | | | | | | | Follow-up to 2ed532ee8c474e9767e76e1f3251cc3a0224358c, a few error messages in the logical replication area currently only deal with tables, but if we're anticipating more relkinds such as sequences being handled, then these messages also fall into the category affected by the previous patch, so adjust them too. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/c9ba5c6a-4bd5-e12c-1b3c-edbcaedbf392@enterprisedb.com
* doc: Document that only superusers can use pg_import_system_collations().Fujii Masao2021-07-21
| | | | | | | | Back-patch to v10 where pg_import_system_collations() was added. Author: Atsushi Torikoshi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com
* Make XLOG_FPI_FOR_HINT records honor full_page_writes setting.Fujii Masao2021-07-21
| | | | | | | | | | | | | | | | Commit 2c03216d83 changed XLOG_FPI_FOR_HINT records so that they always included full-page images even when full_page_writes was disabled. However, in this setting, they don't need to do that because hint bit updates don't need to be protected from torn writes. Therefore, this commit makes XLOG_FPI_FOR_HINT records honor full_page_writes setting. That is, XLOG_FPI_FOR_HINT records may include no full-page images if full_page_writes is disabled, and WAL replay of them does nothing. Reported-by: Zhang Wenjie Author: Kyotaro Horiguchi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/tencent_60F11973A111EED97A8596FFECC4A91ED405@qq.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 22:55:14 +0000