summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* Improve support for UNICODE collation on older ICUPeter Eisentraut2023-03-132-2/+2
| | | | | | | | | The recently added standard collation UNICODE (0d21d4b9bc) doesn't give consistent results on some build farm members with old ICU versions. Apparently, the ICU locale specification 'und' (language tag style) misbehaves on some older ICU versions. Replacing it with '' (ICU locale ID style) fixes it at least on some OS versions. Let's see what the build farm says.
* Fix inconsistent error handling for GSS encryption in PQconnectPoll()Michael Paquier2023-03-131-9/+14
| | | | | | | | | | | | | | | | | | | The error cases for TLS and GSS encryption were inconsistent. After TLS fails, the connection is marked as dead and follow-up calls of PQconnectPoll() would return immediately, but GSS encryption was not doing that, so the connection would still have been allowed to enter the GSS handling code. This was handled incorrectly when gssencmode was set to "require". "prefer" was working correctly, and this could not happen under "disable" as GSS encryption would not be attempted. This commit makes the error handling of GSS encryption on par with TLS portion, fixing the case of gssencmode=require. Reported-by: Jacob Champion Author: Michael Paquier Reviewed-by: Jacob Champion, Stephen Frost Discussion: https://postgr.es/m/23787477-5fe1-a161-6d2a-e459f74c4713@timescale.com Backpatch-through: 12
* meson: Make auto the default of the ssl optionPeter Eisentraut2023-03-133-3/+3
| | | | | | | | | | The 'ssl' option is of type 'combo', but we add a choice 'auto' that simulates the behavior of a feature option. This way, openssl is used automatically by default if present, but we retain the ability to potentially select another ssl library. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/ad65ffd1-a9a7-fda1-59c6-f7dc763c3051%40enterprisedb.com
* Work around implementation restriction in adjust_appendrel_attrs.Tom Lane2023-03-123-4/+53
| | | | | | | | | | | | | | | | | | | | | | | adjust_appendrel_attrs can't transfer nullingrel labeling to a non-Var translation expression (mainly because it's too late to wrap such an expression in a PlaceHolderVar). I'd supposed in commit 2489d76c4 that that restriction was unreachable because we'd not attempt to push problematic clauses down to an appendrel child relation. I forgot that set_append_rel_size blindly converts all the parent rel's joininfo clauses to child clauses, and that list could well contain clauses from above a nulling outer join. We might eventually have to devise a direct fix for this implementation restriction, but for now it seems enough to filter out troublesome clauses while constructing the child's joininfo list. Such clauses are certainly not useful while constructing paths for the child rel; they'll have to be applied later when we join the completed appendrel to something else. So we don't need them here, and omitting them from the list should save a few cycles while processing the child rel. Per bug #17832 from Marko Tiikkaja. Discussion: https://postgr.es/m/17832-d0a8106cdf1b722e@postgresql.org
* Mark unsafe_tests module as not runnable with installcheckAndrew Dunstan2023-03-123-1/+5
| | | | | | | | | | | This was an omission in the original creation of the module. Also slightly adjust some wording to avoid a double "is". Backpatch the non-meson piece of this to release 12, where the module was introduced. Discussion: https://postgr.es/m/be869e1c-8e3f-4cde-8609-212c899cccf9@dunslane.net
* pg_amcheck: Minor test speedupsAndres Freund2023-03-111-18/+15
| | | | | | | | | Freezing the relation N times and fetching the tuples one-by-one isn't that cheap. On my machine this reduces test times by a bit less than one second, on windows CI it's a few seconds. Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com> Discussion: https://postgr.es/m/20230309001558.b7shzvio645ebdta@awork3.anarazel.de
* amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0Andres Freund2023-03-111-8/+20
| | | | | | | | | | | | | | | | | | | 64bit xids can't represent xids before epoch 0 (see also be504a3e974). When FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit xid far into the future. Noticed while adding assertions in the course of investigating be504a3e974, as amcheck's test create such xids. To fix the issue, just return FirstNormalFullTransactionId in this case. A freshly initdb'd cluster already has a newer horizon. The most minimal version of this would make the messages for some detected corruptions differently inaccurate. To make those cases accurate, switch FullTransactionIdFromXidAndCtx() to use the 32bit modulo difference between xid and nextxid to compute the 64bit xid, yielding sensible "in the future" / "in the past" answers. Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com> Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de Backpatch: 14-, where heapam verification was introduced
* Ensure COPY TO on an RLS-enabled table copies no more than it should.Tom Lane2023-03-104-3/+77
| | | | | | | | | | | | | | The COPY documentation is quite clear that "COPY relation TO" copies rows from only the named table, not any inheritance children it may have. However, if you enabled row-level security on the table then this stopped being true, because the code forgot to apply the ONLY modifier in the "SELECT ... FROM relation" query that it constructs in order to allow RLS predicates to be attached. Fix that. Report and patch by Antonin Houska (comment adjustments and test case by me). Back-patch to all supported branches. Discussion: https://postgr.es/m/3472.1675251957@antos
* initdb: derive encoding from locale for ICU; similar to libc.Jeff Davis2023-03-104-19/+15
| | | | | | | | | | | | | | | | Previously, the default encoding was derived from the locale when using libc; while the default was always UTF-8 when using ICU. That would throw an error when the locale was not compatible with UTF-8. This commit causes initdb to derive the default encoding from the locale for both providers. If --no-locale is specified (or if the locale is C or POSIX), the default encoding will be UTF-8 for ICU (because ICU does not support SQL_ASCII) and SQL_ASCII for libc. Per buildfarm failure on system "hoverfly" related to commit 27b62377b4. Discussion: https://postgr.es/m/d191d5841347301a8f1238f609471ddd957fc47e.camel%40j-davis.com
* Fix tests for non-ICU buildPeter Eisentraut2023-03-103-3/+3
| | | | missed in 0d21d4b9bc
* Add standard collation UNICODEPeter Eisentraut2023-03-104-4/+18
| | | | | | | | | | This adds a new predefined collation named UNICODE, which sorts by the default Unicode collation algorithm specifications, per SQL standard. This only works if ICU support is built. Reviewed-by: Jeff Davis <pgsql@j-davis.com> Discussion: https://www.postgresql.org/message-id/flat/1293e382-2093-a2bf-a397-c04e8f83d3c2@enterprisedb.com
* Include headers of archive/ in installationMichael Paquier2023-03-102-1/+2
| | | | | | | | | These new headers have been recently added in 35739b8, but they were not installed. Sravan has provided the patch for configure/make, while I have fixed the meson part. Author: Sravan Kumar, Michael Paquier Discussion: https://postgr.es/m/CA+=NbjguiQy-MbVqfQ-jQ=2Fcmx3Zs36OkKb-vjt28jMTG0OOg@mail.gmail.com
* Add a test for UCS_BASIC collationPeter Eisentraut2023-03-104-0/+30
|
* Fix incorrect format placeholdersPeter Eisentraut2023-03-101-2/+2
|
* Fix test failure caused in 27b62377b4.Jeff Davis2023-03-091-1/+1
| | | | Per buildfarm system "prion".
* Reject combining "epoch" and "infinity" with other datetime fields.Tom Lane2023-03-093-15/+133
| | | | | | | | | | | Datetime input formerly accepted combinations such as '1995-08-06 infinity', but this seems like a clear error. Reject any combination of regular y/m/d/h/m/s fields with these special tokens. Joseph Koshakow, reviewed by Keisuke Kuroda and myself Discussion: https://postgr.es/m/CAAvxfHdm8wwXwG_FFRaJ1nTHiMWb7YXS2YKCzCt8Q0a2ZoMcHg@mail.gmail.com
* Use ICU by default at initdb time.Jeff Davis2023-03-0911-20/+61
| | | | | | | | If the ICU locale is not specified, initialize the default collator and retrieve the locale name from that. Discussion: https://postgr.es/m/510d284759f6e943ce15096167760b2edcb2e700.camel@j-davis.com Reviewed-by: Peter Eisentraut
* Fix 9637badd9f.Jeff Davis2023-03-093-22/+45
| | | | | Discussion: https://postgr.es/m/0a364430-266e-1e1a-d5d8-1a5273c9ddb6@dunslane.net Reported-by: Andrew Dunstan
* pg_upgrade: copy locale and encoding information to new cluster.Jeff Davis2023-03-097-183/+192
| | | | | | | | | | | | | | | | | | Previously, pg_upgrade checked that the old and new clusters were compatible, including the locale and encoding. But the new cluster was just created, and only template0 from the new cluster will be preserved (template1 and postgres are both recreated during the upgrade process). Because template0 is not sensitive to locale or encoding, just update the pg_database entry to be the same as template0 from the original cluster. This commit makes it easier to change the default initdb locale or encoding settings without causing needless incompatibilities. Discussion: https://postgr.es/m/d62b2874-729b-d26a-2d0a-0d64f509eca4@enterprisedb.com Reviewed-by: Peter Eisentraut
* For Kerberos testing, disable reverse DNS lookupStephen Frost2023-03-091-0/+12
| | | | | | | | | | | | | | | | | In our Kerberos test suite, there isn't much need to worry about the normal canonicalization that Kerberos provides by looking up the reverse DNS for the IP address connected to, and in some cases it can actively cause problems (eg: a captive portal wifi where the normally not resolvable localhost address used ends up being resolved anyway, and not to the domain we are using for testing, causing the entire regression test to fail with errors about not being able to get a TGT for the remote realm for cross-realm trust). Therefore, disable it by adding rdns = false into the krb5.conf that's generated for the test. Reviewed-By: Heikki Linnakangas Discussion: https://postgr.es/m/Y/QD2zDkDYQA1GQt@tamriel.snowman.net
* Avoid criticizable perl codeAlvaro Herrera2023-03-091-8/+8
| | | | | | | | | | Using `require` / `->import` instead of `use` avoids the use of a "stringy eval", making for cleaner code that we don't need to silence perlcritic about. Per Andrew Dunstan Discussion: https://postgr.es/m/7cd3bbbd-0216-4436-d571-8f80c9259a07@dunslane.net
* Improve/correct commentsPeter Eisentraut2023-03-091-8/+3
| | | | | | | | | | | | Change comments for pg_cryptohash_init(), pg_cryptohash_update(), pg_cryptohash_final() in cryptohash.c to match cryptohash_openssl.c. In particular, the claim that these functions were "designed" to never fail was incorrect, since by design callers need to be prepared to handle failures, for compatibility with the cryptohash_openssl.c versions. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/301F4EDD-27B9-460F-B462-B9DB2BDE4ACF@yesql.se
* Disallow specifying ICU rules unless locale provider is ICUPeter Eisentraut2023-03-092-0/+10
| | | | | | Follow-up for 30a53b7929; this was not checked in all cases. Reported-by: Jeff Davis <pgsql@j-davis.com>
* Run pgindent on libpq's fe-auth.c, fe-auth-scram.c and fe-connect.cMichael Paquier2023-03-093-60/+60
| | | | | | | | | A patch sent by Jacob Champion has been touching this area of the code, and the set of changes done in a9e9a9f has made a run of pgindent on these files a bit annoying to handle. So let's clean up a bit the area, first, to ease the work on follow-up patches. Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
* Fix race in SERIALIZABLE READ ONLY.Thomas Munro2023-03-091-18/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit bdaabb9b started skipping doomed transactions when building the list of possible conflicts for SERIALIZABLE READ ONLY. That makes sense, because doomed transactions won't commit, but a couple of subtle things broke: 1. If all uncommitted r/w transactions are doomed, a READ ONLY transaction would arbitrarily not benefit from the safe snapshot optimization. It would not be taken immediately, and yet no other transaction would set SXACT_FLAG_RO_SAFE later. 2. In the same circumstances but with DEFERRABLE, GetSafeSnapshot() would correctly exit its wait loop without sleeping and then take the optimization in non-assert builds, but assert builds would fail a sanity check that SXACT_FLAG_RO_SAFE had been set by another transaction. This is similar to the case for PredXact->WritableSxactCount == 0. We should opt out immediately if our possibleUnsafeConflicts list is empty after filtering. The code to maintain the serializable global xmin is moved down below the new opt out site, because otherwise we'd have to reverse its effects before returning. Back-patch to all supported releases. Bug #17368. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu
* meson: tests: Adjust with_icu/ZSTD env vars for pg_dump, pg_basebackupAndres Freund2023-03-082-1/+2
| | | | | | | | | 396d348b0 omitted adding with_icu to the pg_dump tests under meson. Conversely, e6927270c exported ZSTD for pg_basebackup's tests, despite pg_basebackup's ZSTD support not having any tests. Reported-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20230226225239.GL1653@telsasoft.com
* meson: Add target for installing test files & improve install_test_filesAndres Freund2023-03-081-10/+15
| | | | | | | | | | | | | | | | | | | | The changes in b6a0d469cae prevented installation of the test files during a normal install. However, the buildfarm intentionally tries to trun the tests against a "real" installation. The new install-test-files target provides that ability. Because we want to install into a normal directory, I removed the necessary munging of the target paths from meson.build and moved it into install-test-files. I also added DESTDIR support, so that installing can redirect the directory if desired. That's used for the tmp_install/ installation now. I didn't like the number of arguments necessary for install_test_files, so I changed it to use --install target list of files which makes it easier to use for further directories, if/when we need them. Discussion: https://postgr.es/m/20230308012940.edexipb3vqylcu6r@awork3.anarazel.de
* 001_libpq_pipeline.pl: use Test::Differences if availableAlvaro Herrera2023-03-082-1/+17
| | | | | | | | When one of these tests fails to match the trace, this better shows what the problem is. Discussion: https://postgr.es/m/20220617183150.ilgokxp22mzywnhh@alvherre.pgsql Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
* Allow tailoring of ICU locales with custom rulesPeter Eisentraut2023-03-0817-59/+306
| | | | | | | | | | | | This exposes the ICU facility to add custom collation rules to a standard collation. New options are added to CREATE COLLATION, CREATE DATABASE, createdb, and initdb to set the rules. Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Daniel Verite <daniel@manitou-mail.org> Discussion: https://www.postgresql.org/message-id/flat/821c71a4-6ef0-d366-9acf-bb8e367f739f@enterprisedb.com
* Clean up commentsPeter Eisentraut2023-03-081-17/+53
| | | | | | Reformat some of the comments in MergeAttributes(). A lot of code has been added here over time, and the comments could use a bit of editing to make the code flow read better.
* Break up long GETTEXT_FILES listsPeter Eisentraut2023-03-0812-31/+138
| | | | | | One file per line seems best. We already did this in some cases. This adopts the same format everywhere (except in some cases where the list reasonably fits on one line).
* Update commentPeter Eisentraut2023-03-081-2/+1
| | | | | | There was apparently an attempt here to list all the object types that ACL_USAGE applies to, but it wasn't complete. So instead of trying to keep up, put in a more timeless comment.
* Fix corruption due to vacuum_defer_cleanup_age underflowing 64bit xidsAndres Freund2023-03-071-12/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When vacuum_defer_cleanup_age is bigger than the current xid, including the epoch, the subtraction of vacuum_defer_cleanup_age would lead to a wrapped around xid. While that normally is not a problem, the subsequent conversion to a 64bit xid results in a 64bit-xid very far into the future. As that xid is used as a horizon to detect whether rows versions are old enough to be removed, that allows removal of rows that are still visible (i.e. corruption). If vacuum_defer_cleanup_age was never changed from the default, there is no chance of this bug occurring. This bug was introduced in dc7420c2c92. A lesser version of it exists in 12-13, introduced by fb5344c969a, affecting only GiST. The 12-13 version of the issue can, in rare cases, lead to pages in a gist index getting recycled too early, potentially causing index entries to be found multiple times. The fix is fairly simple - don't allow vacuum_defer_cleanup_age to retreat further than FirstNormalTransactionId. Patches to make similar bugs easier to find, by adding asserts to the 64bit xid infrastructure, have been proposed, but are not suitable for backpatching. Currently there are no tests for vacuum_defer_cleanup_age. A patch introducing infrastructure to make writing a test easier has been posted to the list. Reported-by: Michail Nikolaev <michail.nikolaev@gmail.com> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de Backpatch: 12-, but impact/fix is smaller for 12-13
* Refine query jumbling handling for CallStmtMichael Paquier2023-03-081-2/+6
| | | | | | | | | | Previously, all the nodes of CallStmt were included in the jumbling, causing a duplicate in the computation as the transformed state of the CALL query was included as well as the parsed state (transformed FuncCall with all the input arguments and potential output arguments). Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
* meson: don't require 'touch' binary, make use of 'cp' optionalAndres Freund2023-03-071-2/+2
| | | | | | | | | | | | We already didn't use touch (some earlier version of the meson build did ), and cp is only used for updating unicode files. The latter already depends on the optional availability of 'wget', so doing the same for 'cp' makes sense. Eventually we probably want a portable command for updating source code as part of a target, but for now... Reported-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/70e96c34-64ee-e549-8c4a-f91a7a668804@dunslane.net
* Ignore IntoClause.viewQuery in query jumblingMichael Paquier2023-03-081-3/+6
| | | | | | | | | | | | | | | | | | IntoClause.viewQuery is a copy of the parsed-but-not-rewritten SELECT clause copied to IntoClause when transforming CreateTableAsStmt for a materialized view. Including a second copy of the SELECT Query into the query jumbling was leading to an incorrect numbering of the Const node locations, as these would be counted twice instead of once. This becomes visible once the query normalization is applied to CREATE MATERIALIZED VIEW in pg_stat_statements in the shape of a query string using only odd numbers for the normalized constants, (regression tests added in pg_stat_statements as of de2aca2 would show the difference). Including the original Query from CreateTableAsStmt is enough for the query jumbling. Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
* Improve readability of code PROCESS_MAIN in vacuum_rel()Michael Paquier2023-03-081-13/+21
| | | | | | | | | | | | | | 4211fbd has been handling PROCESS_MAIN in vacuum_rel() with an "if/else if" structure to avoid an extra level of indentation, but this has been found as being rather parse to read. This commit updates the code so as we check for PROCESS_MAIN in a single place and then handle its subpaths, FULL or non-FULL vacuums. Some comments are added to make that clearer for the reader. Reported-by: Melanie Plageman Author: Nathan Bossart Reviewed-by: Michael Paquier, Melanie Plageman Discussion: https://postgr.es/m/20230306194009.5cn6sp3wjotd36nu@liskov
* Fix more bugs caused by adding columns to the end of a view.Tom Lane2023-03-074-13/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If a view is defined atop another view, and then CREATE OR REPLACE VIEW is used to add columns to the lower view, then when the upper view's referencing RTE is expanded by ApplyRetrieveRule we will have a subquery RTE with fewer eref->colnames than output columns. This confuses various code that assumes those lists are always in sync, as they are in plain parser output. We have seen such problems before (cf commit d5b760ecb), and now I think the time has come to do what was speculated about in that commit: let's make ApplyRetrieveRule synthesize some column names to preserve the invariant that holds in parser output. Otherwise we'll be chasing this class of bugs indefinitely. Moreover, it appears from testing that this actually gives us better results in the test case d5b760ecb added, and likely in other corner cases that we lack coverage for. In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with an elog(ERROR) call, since the case is now presumably unreachable. But it seems like changing that in back branches would bring more risk than benefit, so there I just updated the comment. Per bug #17811 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/17811-d31686b78f0dffc9@postgresql.org
* Add support for unit "B" to pg_size_bytes()Peter Eisentraut2023-03-073-12/+38
| | | | | | | | This makes it consistent with the units support in GUC. Reviewed-by: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/0106914a-9eb5-22be-40d8-652cc88c827d%40enterprisedb.com
* Fix flakey pg_stat_io testAndres Freund2023-03-072-0/+8
| | | | | | | | | | Wrap test of pg_stat_io's tracking of shared buffer reads in a transaction to prevent concurrent accesses (e.g. by autovacuum) causing spurious test failures. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Author: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://www.postgresql.org/message-id/20230306190919.ai6mxdq3sygyyths%40awork3.anarazel.de
* Make get_extension_schema() availableMichael Paquier2023-03-072-1/+2
| | | | | | | | | | | This routine is able to retrieve the OID of the schema used with an extension (pg_extension.extnamespace), or InvalidOid if this information is not available. plpgsql_check embeds a copy of this code when performing checks on functions, as one out-of-core example. Author: Pavel Stehule Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/CAFj8pRD+9x55hjDoi285jCcjPc8uuY_D+FLn5RpXggdz+4O2sQ@mail.gmail.com
* Fix incorrect comment in pg_get_partkeydef()David Rowley2023-03-071-1/+1
| | | | | | | | | The comment claimed the output of the function was prefixed by "PARTITION BY". This is incorrect. Author: Japin Li Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/MEYP282MB166923B446FF5FE55B9DACB7B6B69@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
* Fix some more cases of missed GENERATED-column updates.Tom Lane2023-03-068-207/+280
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If UPDATE is forced to retry after an EvalPlanQual check, it neglected to repeat GENERATED-column computations, even though those might well have changed since we're dealing with a different tuple than before. Fixing this is mostly a matter of looping back a bit further when we retry. In v15 and HEAD that's most easily done by altering the API of ExecUpdateAct so that it includes computing GENERATED expressions. Also, if an UPDATE in a partitioned table turns into a cross-partition INSERT operation, we failed to recompute GENERATED columns. That's a bug since 8bf6ec3ba allowed partitions to have different generation expressions; although it seems to have no ill effects before that. Fixing this is messier because we can now have situations where the same query needs both the UPDATE-aligned set of GENERATED columns and the INSERT-aligned set, and it's unclear which set will be generated first (else we could hack things by forcing the INSERT-aligned set to be generated, which is indeed how fe9e658f4 made it work for MERGE). The best fix seems to be to build and store separate sets of expressions for the INSERT and UPDATE cases. That would create ABI issues in the back branches, but so far it seems we can leave this alone in the back branches. Per bug #17823 from Hisahiro Kauchi. The first part of this affects all branches back to v12 where GENERATED columns were added. Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org
* Silence -Wmissing-braces complaints in file_utils.cMichael Paquier2023-03-071-1/+1
| | | | | | | Per buildfarm member lapwing, coupled with an offline poke from Julien Rouhaud. 6392f2a was a similar case.
* Fill EState.es_rteperminfos more systematically.Tom Lane2023-03-066-16/+21
| | | | | | | | | | | | | | | | | | While testing a fix for bug #17823, I discovered that EvalPlanQualStart failed to copy es_rteperminfos from the parent EState, resulting in failure if anything in EPQ execution wanted to consult that information. This led me to conclude that commit a61b1f748 had been too haphazard about where to fill es_rteperminfos, and that we need to be sure that that happens exactly where es_range_table gets filled. So I changed the signature of ExecInitRangeTable to help ensure that this new requirement doesn't get missed. (Indeed, pgoutput.c was also failing to fill it. Maybe we don't ever need it there, but I wouldn't bet on that.) No test case yet; one will arrive with the fix for #17823. But that needs to be back-patched, while this fix is HEAD-only. Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org
* Reword overly-optimistic comment about backup checksum verification.Robert Haas2023-03-061-5/+15
| | | | | | | | | | The comment implies that a single retry is sufficient to avoid spurious checksum failures, but in fact no number of retries is sufficient for that purpose. Update the comment accordingly. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com
* Remove an old comment that doesn't seem especially useful.Robert Haas2023-03-061-7/+0
| | | | | | | | | | | | The functions that follow are concerned with various things, of which the tar format is only one, so this comment doesn't really seem helpful. The file isn't really divided into sections in the way that this comment seems to contemplate -- or at least, not any more. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com
* In basebackup.c, perform end-of-file test after checksum validation.Robert Haas2023-03-061-8/+9
| | | | | | | | | | | | | | | | | | | | We read blocks of data from files that we're backing up in chunks, some multiple of BLCKSZ for each read. If checksum verification fails, we then try rereading just the one block for which validation failed. If that block happened to be the first block of the chunk, and if the file was concurrently truncated to remove that block, then we'd reach a call to bbsink_archive_contents() with a buffer length of 0. That causes an assertion failure. As far as I can see, there are no particularly bad consequences if this happens in a non-assert build, and it's pretty unlikely to happen in the first place because it requires a series of somewhat unlikely things to happen in very quick succession. However, assertion failures are bad, so rearrange the code to avoid that possibility. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com
* Fix handling of default option values in createuserDaniel Gustafsson2023-03-062-16/+23
| | | | | | | | | | | | | | | | Add description of which one is the default between two complementary options of --bypassrls and --replication in the help text and docs. In correspondence let the command always include the tokens corresponding to every options of that kind in the SQL command sent to server. Tests are updated accordingly. Also fix the checks of some trivalue vars which were using literal zero for checking default value instead of the enum label TRI_DEFAULT. While not a bug, since TRI_DEFAULT is defined as zero, fixing improves read- ability improved readability (and avoid bugs if the enum is changed). Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20220810.151243.1073197628358749087.horikyota.ntt@gmail.com
* Add PROCESS_MAIN to VACUUMMichael Paquier2023-03-068-15/+128
| | | | | | | | | | | | | | | | | | | | | | | | | Disabling this option is useful to run VACUUM (with or without FULL) on only the toast table of a relation, bypassing the main relation. This option is enabled by default. Running directly VACUUM on a toast table was already possible without this feature, by using the non-deterministic name of a toast relation (as of pg_toast.pg_toast_N, where N would be the OID of the parent relation) in the VACUUM command, and it required a scan of pg_class to know the name of the toast table. So this feature is basically a shortcut to be able to run VACUUM or VACUUM FULL on a toast relation, using only the name of the parent relation. A new switch called --no-process-main is added to vacuumdb, to work as an equivalent of PROCESS_MAIN. Regression tests are added to cover VACUUM and VACUUM FULL, looking at pg_stat_all_tables.vacuum_count to see how many vacuums have run on each table, main or toast. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
View Lorry Controller Status