aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Fix corner-case planner failure for MERGE.Tom Lane2023-03-28
| | | | | | | | | | | | | | | | | | | | | MERGE planning could fail with "variable not found in subplan target list" if the target table is partitioned and all its partitions are excluded at plan time, or in the case where it has no partitions but used to have some. This happened because distribute_row_identity_vars thought it didn't need to make the target table's reltarget list fully valid; but if we generate a join plan then that is required because the dummy Result node's tlist will be made from the reltarget. The same logic appears in distribute_row_identity_vars in v14, but AFAICS the problem is unreachable in that branch for lack of MERGE. In other updating statements, the target table is always inner-joined to any other tables, so if the target is known dummy then the whole plan reduces to dummy, so no join nodes are created. So I'll refrain from back-patching this code change to v14 for now. Per report from Alvaro Herrera. Discussion: https://postgr.es/m/20230328112248.6as34mlx5sr4kltg@alvherre.pgsql
* initdb: emit message when using default ICU locale.Jeff Davis2023-03-28
| | | | | | | | Helpful to determine from test logs whether the locale came from the environment or a command-line option. Discussion: https://postgr.es/m/04182066-7655-344a-b8b7-040b1b2490fb%40enterprisedb.com Reviewed-by: Peter Eisentraut
* initdb: replace check_icu_locale() with default_icu_locale().Jeff Davis2023-03-28
| | | | | | | | | | | | | The extra checks done in check_icu_locale() are not necessary. An existing comment already pointed out that the checks would be done during post-bootstrap initialization, when the locale is opened by the backend. This was a mistake in commit 27b62377b4. This commit creates a simpler function default_icu_locale() to just return the locale of the default collator. Discussion: https://postgr.es/m/04182066-7655-344a-b8b7-040b1b2490fb%40enterprisedb.com Reviewed-by: Peter Eisentraut
* Fix error inconsistency in older ICU versions.Jeff Davis2023-03-28
| | | | | | | | | | | | | | | | | | To support older ICU versions, we rely on icu_set_collation_attributes() to do error checking that is handled directly by ucol_open() in newer ICU versions. Commit 3b50275b12 introduced a slight inconsistency, where the error report includes the fixed-up locale string, rather than the locale string passed to pg_ucol_open(). Refactor slightly so that pg_ucol_open() handles the errors from both ucol_open() and icu_set_collation_attributes(), making it easier to see any differences between the error reports. It also makes pg_ucol_open() responsible for closing the UCollator on error, which seems like the right place. Discussion: https://postgr.es/m/04182066-7655-344a-b8b7-040b1b2490fb%40enterprisedb.com Reviewed-by: Peter Eisentraut
* Save a few bytes in pg_attributePeter Eisentraut2023-03-28
| | | | | | | | | | | | | | | | | Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
* pg_walinspect: Adjust memory context name.Peter Geoghegan2023-03-27
| | | | | | | Correct the name of the memory context used by the pg_get_wal_block_info() SQL-callable function. Oversight in commit 9ecb134a93.
* Generate a few more functions of pgstatfuncs.c with macrosMichael Paquier2023-03-28
| | | | | | | | | | | | | | Two new macros are added with their respective functions switched to use them. These are for functions with millisecond stats, with and without "xact" in their names (for the stats that can be tracked within a transaction). While on it, prefix the macro for float8 on database entries with "_MS", as it does a us->ms conversion, based on a suggestion from Andres Freund. Author: Bertrand Drouvot Discussion: https://postgr.es/m/6e2efb4f-6fd0-807e-f6bf-94207db8183a@gmail.com
* Reject attempts to alter composite types used in indexes.Tom Lane2023-03-27
| | | | | | | | | | | | | | | | | | | | find_composite_type_dependencies() ignored indexes, which is a poor decision because an expression index could have a stored column of a composite (or other container) type even when the underlying table does not. Teach it to detect such cases and error out. We have to work a bit harder than for other relations because the pg_depend entry won't identify the specific index column of concern, but it's not much new code. This does not address bug #17872's original complaint that dropping a column in such a type might lead to violations of the uniqueness property that a unique index is supposed to ensure. That seems of much less concern to me because it won't lead to crashes. Per bug #17872 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/17872-d0fbb799dc3fd85d@postgresql.org
* amcheck: Generalize one of the recently-added update chain checks.Robert Haas2023-03-27
| | | | | | | | | | | | | | | | | | | | Commit bbc1376b39627c6bddd8a0dc0a7dda24c91a97a0 checked that if a redirected line pointer pointed to a tuple, the tuple should be marked both HEAP_ONLY_TUPLE and HEAP_UPDATED. But Andres Freund pointed out that *any* tuple that is marked HEAP_ONLY_TUPLE should be marked HEAP_UPDATED, not just one that is the target of a redirected line pointer. Do that instead. To see why this is better, consider a redirect line pointer A which points to a heap-only tuple B which points (via CTID) to another heap-only tuple C. With the old code, we'd complain if B was not marked HEAP_UPDATED, but with this change, we'll complain if either B or C is not marked HEAP_UPDATED. (Note that, with or without this commit, if either B or C were not marked HEAP_ONLY_TUPLE, we would also complain about that.) Discussion: http://postgr.es/m/CA%2BTgmobLypZx%3DcOH%2ByY1GZmCruaoucHm77A6y_-Bo%3Dh-_3H28g%40mail.gmail.com
* amcheck: Tighten up validation of redirect line pointers.Robert Haas2023-03-27
| | | | | | | | | | | | | | | | | | | | | | | | Commit bbc1376b39627c6bddd8a0dc0a7dda24c91a97a0 added a new lp_valid[] array which records whether or not a line pointer was thought to be valid, but entries could sometimes get set to true in cases where that wasn't actually safe. Fix that. Suppose A is a redirect line pointer and B is the other line pointer to which it points. The old code could mishandle this situation in a couple of different ways. First, if B was unused, we'd complain about corruption but still set lp_valid[A] = true, causing later code to try to access the B as if it were pointing to a tuple. Second, if B was dead, we wouldn't complain about corruption at all, which is an oversight, and would also set lp_valid[A] = true, which would again confuse later code. Fix all that. In the case where B is a redirect, the old code was correct, but refactor things a bit anyway so that all of these cases are handled more symmetrically. Also add an Assert() and some comments. Andres Freund and Robert Haas Discussion: http://postgr.es/m/20230323172607.y3lejpntjnuis5vv%40awork3.anarazel.de
* doc: fix Apple Silicon Homebrew prefix change documentationDaniel Gustafsson2023-03-27
| | | | | | | | | | Commit 4c8d65408 incorrectly stated that Homebrew has changed its prefix for Apple M1 machines, but the prefix change applies to all Apple Silicon based machines. Fix by writing Apple Silicon instead of Apple M1. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/87mt3ys8ng.fsf@wibble.ilmari.org
* doc: Fix XML_CATALOG_FILES env var for Apple M1 machinesDaniel Gustafsson2023-03-27
| | | | | | | | | | | Homebrew changed the prefix for Apple M1 based machines, so our advice for XML_CATALOG_FILES needs to mention both. More info on the Homebrew change can be found at: https://github.com/Homebrew/brew/issues/9177 Author: Julien Rouhaud <julien.rouhaud@free.fr> Discussion: https://postgr.es/m/20230327082441.h7pa2vqiobbyo7rd@jrouhaud
* Make SCRAM iteration count configurableDaniel Gustafsson2023-03-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the hardcoded value with a GUC such that the iteration count can be raised in order to increase protection against brute-force attacks. The hardcoded value for SCRAM iteration count was defined to be 4096, which is taken from RFC 7677, so set the default for the GUC to 4096 to match. In RFC 7677 the recommendation is at least 15000 iterations but 4096 is listed as a SHOULD requirement given that it's estimated to yield a 0.5s processing time on a mobile handset of the time of RFC writing (late 2015). Raising the iteration count of SCRAM will make stored passwords more resilient to brute-force attacks at a higher computational cost during connection establishment. Lowering the count will reduce computational overhead during connections at the tradeoff of reducing strength against brute-force attacks. There are however platforms where even a modest iteration count yields a too high computational overhead, with weaker password encryption schemes chosen as a result. In these situations, SCRAM with a very low iteration count still gives benefits over weaker schemes like md5, so we allow the iteration count to be set to one at the low end. The new GUC is intentionally generically named such that it can be made to support future SCRAM standards should they emerge. At that point the value can be made into key:value pairs with an undefined key as a default which will be backwards compatible with this. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Jonathan S. Katz <jkatz@postgresql.org> Discussion: https://postgr.es/m/F72E7BC7-189F-4B17-BF47-9735EB72C364@yesql.se
* meson: Fix support for empty darwin sysrootPeter Eisentraut2023-03-27
| | | | | | | | The -isysroot options should only be added if the sysroot resolved to a nonempty string. This matches the behavior in src/template/darwin (also documented in installation.sgml). Discussion: https://www.postgresql.org/message-id/flat/60765bf0-5027-4b23-9f78-4a365d28823f%40enterprisedb.com
* Improve a few things in pg_walinspectMichael Paquier2023-03-27
| | | | | | | | | | | | | | | | This improves a few things in pg_walinspect: - Return NULL rather than empty strings in pg_get_wal_records_info() for the block references and the record description if there is no information provided by the fallback. This point has been raised by Peter Geoghegan. - Add a check on XLogRecHasAnyBlockRefs() for pg_get_wal_block_info(), to directly skip records that have no block references. This speeds up the function a bit, depending on the number of records that have no block references. Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/CALj2ACWL9RG8sGJHinggRNBTxgRWJTSxCkB+cE6=t3Phh=Ey+A@mail.gmail.com
* Generate pg_stat_get_xact*() functions for relations using macrosMichael Paquier2023-03-27
| | | | | | | | | | This change replaces seven functions definitions by macros. This is the same idea as 8018ffb or 83a1a1b, taking advantage of the variable rename done in 8089517 for relation entries. Author: Bertrand Drouvot Discussion: https://postgr.es/m/631e3084-c5d9-8463-7540-fcff4674caa5@gmail.com
* Doc: clarify introduction to database roles.Tom Lane2023-03-26
| | | | | | | | | | | | | | | | Word-smith section 22.1 ("Database Roles") a little bit in hopes of removing confusion about how the bootstrap superuser's name is chosen. While here, I couldn't help noticing that the claim that the bootstrap superuser is the only initially-existing role has been a lie since we started to invent predefined roles. We don't want too much detail in this very introductory text, but it seems worth changing it to say that it's the only initially-existing login-capable role. Per documentation comment from Maja Zaloznik. Discussion: https://postgr.es/m/167931662853.3349090.18217722739345182859@wrigleys.postgresql.org
* Fix oversights in array manipulation.Tom Lane2023-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nested-arrays code path in ExecEvalArrayExpr() used palloc to allocate the result array, whereas every other array-creating function has used palloc0 since 18c0b4ecc. This mostly works, but unused bits past the end of the nulls bitmap may end up undefined. That causes valgrind complaints with -DWRITE_READ_PARSE_PLAN_TREES, and could cause planner misbehavior as cited in 18c0b4ecc. There seems no very good reason why we should strive to avoid palloc0 in just this one case, so fix it the easy way with s/palloc/palloc0/. While looking at that I noted that we also failed to check for overflow of "nbytes" and "nitems" while summing the sizes of the sub-arrays, potentially allowing a crash due to undersized output allocation. For "nbytes", follow the policy used by other array-munging code of checking for overflow after each addition. (As elsewhere, the last addition of the array's overhead space doesn't need an extra check, since palloc itself will catch a value between 1Gb and 2Gb.) For "nitems", there's no very good reason to sum the inputs at all, since we can perfectly well use ArrayGetNItems' result instead of ignoring it. Per discussion of this bug, also remove redundant zeroing of the nulls bitmap in array_set_element and array_set_slice. Patch by Alexander Lakhin and myself, per bug #17858 from Alexander Lakhin; thanks also to Richard Guo. These bugs are a dozen years old, so back-patch to all supported branches. Discussion: https://postgr.es/m/17858-8fd287fd3663d051@postgresql.org
* Add SysCacheGetAttrNotNull for guaranteed not-null attrsDaniel Gustafsson2023-03-25
| | | | | | | | | | | | | When extracting an attr from a cached tuple in the syscache with SysCacheGetAttr the isnull parameter must be checked in case the attr cannot be NULL. For cases when this is known beforehand, a wrapper is introduced which perform the errorhandling internally on behalf of the caller, invoking an elog in case of a NULL attr. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/AD76405E-DB45-46B6-941F-17B1EB3A9076@yesql.se
* Comment on expectations for AutoVacuumWorkItem handlers.Noah Misch2023-03-25
| | | | | This might prevent a repeat of the brin_summarize_range() vulnerability that commit a117cebd638dd02e5c2e791c25e43745f233111b fixed.
* Fix CREATE INDEX progress reporting for multi-level partitioning.Tom Lane2023-03-25
| | | | | | | | | | | | | | | | | | | | | | | The "partitions_total" and "partitions_done" fields were updated as though the current level of partitioning was the only one. In multi-level cases, not only could partitions_total change over the course of the command, but partitions_done could go backwards or exceed the currently-reported partitions_total. Fix by setting partitions_total to the total number of direct and indirect children once at command start, and then just incrementing partitions_done at appropriate points. Invent a new progress monitoring function "pgstat_progress_incr_param" to simplify doing the latter. We can avoid adding cost for the former when doing CREATE INDEX, because ProcessUtility already enumerates the children and it's pretty easy to pass the count down to DefineIndex. In principle the same could be done in ALTER TABLE, but that's structurally difficult; for now, just eat the cost of an extra find_all_inheritors scan in that case. Ilya Gladyshev and Justin Pryzby Discussion: https://postgr.es/m/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel@gmail.com
* Fix abbreviated keys bug introduced in d87d548cd03.Jeff Davis2023-03-25
| | | | | Discussion: http://postgr.es/m/CAMkU=1z17XJatF-rMCY3Cjqcxer-Kyn57x6h3OSCpJ0LpAp0ig@mail.gmail.com Reported-by: Jeff Janes
* Doc: fix another "contents...exceed the available area" PDF warning.Tom Lane2023-03-25
| | | | New since yesterday :-(
* Doc: fix examples for pg_input_error_info().Tom Lane2023-03-24
| | | | | | | | | | | These were causing "contents ... exceed the available area" warnings in PDF builds, and also didn't quite follow our markup conventions for function examples. To fix the overwidth problem, reduce the number of fields shown in one example, and also insert &zwsp; to let the header line be broken in a reasonable place. Discussion: https://postgr.es/m/20230324194701.dqkzcdtlcikseo22@awork3.anarazel.de
* docs: Explain how to silence overly verbose messages by fopAndres Freund2023-03-24
| | | | | Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20230324194701.dqkzcdtlcikseo22@awork3.anarazel.de
* Invent GENERIC_PLAN option for EXPLAIN.Tom Lane2023-03-24
| | | | | | | | | | | | | | | | | This provides a very simple way to see the generic plan for a parameterized query. Without this, it's necessary to define a prepared statement and temporarily change plan_cache_mode, which is a bit tedious. One thing that's a bit of a hack perhaps is that we disable execution-time partition pruning when the GENERIC_PLAN option is given. That's because the pruning code may attempt to fetch the value of one of the parameters, which would fail. Laurenz Albe, reviewed by Julien Rouhaud, Christoph Berg, Michel Pelletier, Jim Jones, and myself Discussion: https://postgr.es/m/0a29b954b10b57f0d135fe12aa0909bd41883eb0.camel@cybertec.at
* meson: Fix oversight in install-quietAndres Freund2023-03-24
| | | | | | | | | | In e522049f239 I accidentally forgot to add meson_bin to the argument list for install-quiet. That kind of works on some platforms because the executable is just 'python', wich the path to meson in an argument. But on windows meson might be installed as an executable. Reported-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/b36dd6a4-748a-4737-54d5-dc8a50fdbe4b@dunslane.net
* Avoid potential UCollator leak for older ICU versions.Jeff Davis2023-03-24
| | | | | | | | | ICU versions 53 and earlier rely on icu_set_collation_attributes() to process the attributes in the locale string. Avoid leaking the already-opened UCollator object if an error is encountered. Discussion: https://postgr.es/m/04182066-7655-344a-b8b7-040b1b2490fb%40enterprisedb.com Reviewed-by: Peter Eisentraut
* pg_locale.c: change ereport() to elog().Jeff Davis2023-03-24
| | | | | Discussion: https://postgr.es/m/73553013-3926-0f34-0fb8-f37909fe4902@enterprisedb.com Reported-by: Peter Eisentraut
* amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.Robert Haas2023-03-24
| | | | | | | | | | | | | | | | | | | | | | | In such cases, get_xid_status() doesn't set its output parameter (the third argument), so we shouldn't fall through to code which will test the value of that parameter. There are five existing calls to get_xid_status(), three of which seem to already handle this case properly. This commit tries to fix the other two. If we're checking xmin and find that it is invalid (i.e. 0) just report that as corruption, similar to what's already done in the three cases that seem correct. If we're checking xmax and find that's invalid, that's fine: it just means that the tuple hasn't been updated or deleted. Thanks to Andres Freund and valgrind for finding this problem, and also to Andres for having a look at the patch. This bug seems to go all the way back to where verify_heapam was first introduced, but wasn't detected until recently, possibly because of the new test cases added for update chain verification. Back-patch to v14, where this code showed up. Discussion: http://postgr.es/m/CA+TgmoZAYzQZqyUparXy_ks3OEOfLD9-bEXt8N-2tS1qghX9gQ@mail.gmail.com
* Fix typo in header commentDaniel Gustafsson2023-03-24
| | | | | | | | Commit 4c04be9b0 accidentally left off the _id portion of the function name in the header comment. Author: Junwang Zhao <zhjwpku@gmail.com> Discussion: https://postgr.es/m/CAEG8a3LP+ytnAXSzR=yiEaQrde+iCybMHsuPn9n=UN3puV_1tw@mail.gmail.com
* Fix incorrect format placeholdersPeter Eisentraut2023-03-24
| | | | | | The fields of NLSVERSIONINFOEX are of type DWORD, which is unsigned long, so the results of the computations being printed are also of type unsigned long.
* meson: docs: add texinfo targetAndres Freund2023-03-23
|
* libpq: Add sslcertmode option to control client certificatesMichael Paquier2023-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sslcertmode option controls whether the server is allowed and/or required to request a certificate from the client. There are three modes: - "allow" is the default and follows the current behavior, where a configured client certificate is sent if the server requests one (via one of its default locations or sslcert). With the current implementation, will happen whenever TLS is negotiated. - "disable" causes the client to refuse to send a client certificate even if sslcert is configured or if a client certificate is available in one of its default locations. - "require" causes the client to fail if a client certificate is never sent and the server opens a connection anyway. This doesn't add any additional security, since there is no guarantee that the server is validating the certificate correctly, but it may helpful to troubleshoot more complicated TLS setups. sslcertmode=require requires SSL_CTX_set_cert_cb(), available since OpenSSL 1.0.2. Note that LibreSSL does not include it. Using a connection parameter different than require_auth has come up as the simplest design because certificate authentication does not rely directly on any of the AUTH_REQ_* codes, and one may want to require a certificate to be sent in combination of a given authentication method, like SCRAM-SHA-256. TAP tests are added in src/test/ssl/, some of them relying on sslinfo to check if a certificate has been set. These are compatible across all the versions of OpenSSL supported on HEAD (currently down to 1.0.1). Author: Jacob Champion Reviewed-by: Aleksander Alekseev, Peter Eisentraut, David G. Johnston, Michael Paquier Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
* meson: add install-{quiet, world} targetsAndres Freund2023-03-23
| | | | | | | To define our own install target, we need dependencies on the i18n targets, which we did not collect so far. Discussion: https://postgr.es/m/3fc3bb9b-f7f8-d442-35c1-ec82280c564a@enterprisedb.com
* meson: add install-{docs,doc-html,doc-man} targetsAndres Freund2023-03-23
| | | | Discussion: https://postgr.es/m/3fc3bb9b-f7f8-d442-35c1-ec82280c564a@enterprisedb.com
* meson: make install_test_files more generic, rename to install_filesAndres Freund2023-03-23
| | | | | | | Now it supports installing directories and directory contents as well. This will be used in a subsequent patch to install documentation. Discussion: https://postgr.es/m/3fc3bb9b-f7f8-d442-35c1-ec82280c564a@enterprisedb.com
* Doc: Improve description of the "batch_size" option for postgres_fdw.Etsuro Fujita2023-03-24
| | | | | | | | | | | Document that the actual number of rows postgres_fdw inserts at once in the COPY case is determined in a similar way to the INSERT case, but it has a restriction that does not apply to the INSERT case. Follow-up for commit 97da48246. Reviewed-by: Daniel Gustafsson and Tatsuo Ishii Discussion: https://postgr.es/m/CAPmGK14NMXDMW4qK9kHUzudN9t71uvrMKPna02X6zwgQJ6E1_g%40mail.gmail.com
* Rewrite error message related to sslmode in libpqMichael Paquier2023-03-24
| | | | | | | | | | | The same error message will be used for a different option, to be introduced in a separate patch. Reshaping the error message as done here saves in translation. Extracted from a larger patch by the same author. Author: Jacob Champion Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
* Rename fields in pgstat structures for functions and relationsMichael Paquier2023-03-24
| | | | | | | | | | | | | | | | | This commit renames the members of a few pgstat structures related to functions and relations, by respectively removing their prefix "f_" and "t_". The statistics for functions and relations and handled in their own file, and pgstatfuncs.c associates each field in a structure variable named based on the object type handled, so no information is lost with this rename. This will help with some of the refactoring aimed for pgstatfuncs.c, as this makes more consistent the field names with the SQL functions retrieving them. Author: Bertrand Drouvot Reviewed-by: Michael Paquier, Melanie Plageman Discussion: https://postgr.es/m/9142f62a-a422-145c-bde0-b5bc498a4ada@gmail.com
* Implement find_my_exec()'s path normalization using realpath(3).Tom Lane2023-03-23
| | | | | | | | | | | | | | | | | | Replace the symlink-chasing logic in find_my_exec with realpath(3), which has been required by POSIX since SUSv2. (Windows lacks realpath(), but there we can use _fullpath() which is functionally equivalent.) The main benefit of this is that -- on all modern platforms at least -- realpath() avoids the chdir() shenanigans we used to perform while interpreting symlinks. That had various corner-case failure modes so it's good to get rid of it. There is still ongoing discussion about whether we could skip the replacement of symlinks in some cases, but that's really matter for a separate patch. Meanwhile I want to push this before we get too close to feature freeze, so that we can find out if there are showstopper portability issues. Discussion: https://postgr.es/m/797232.1662075573@sss.pgh.pa.us
* doc: fix another case of missing productname markupDaniel Gustafsson2023-03-23
| | | | | | | | As a follow-up commit to 0f85db92b9, this adds <productname> markup to another case of "PostgreSQL". Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Discussion: https://postgr.es/m/TYAPR01MB58667A7C8317E267467CC599F5869@TYAPR01MB5866.jpnprd01.prod.outlook.com
* Count updates that move row to a new page.Peter Geoghegan2023-03-23
| | | | | | | | | | | | | | | | | | Add pgstat counter to track row updates that result in the successor version going to a new heap page, leaving behind an original version whose t_ctid points to the new version. The current count is shown by the n_tup_newpage_upd column of each of the pg_stat_*_tables views. The new n_tup_newpage_upd column complements the existing n_tup_hot_upd and n_tup_upd columns. Tables that have high n_tup_newpage_upd values (relative to n_tup_upd) are good candidates for tuning heap fillfactor. Corey Huinker, with small tweaks by me. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zcKpUQMds__Xm2pxLfHKA@mail.gmail.com
* Handle the "und" locale in ICU versions 54 and older.Jeff Davis2023-03-23
| | | | | | | | | | | | | | | | | | | | | | The "und" locale is an alternative spelling of the root locale, but it was not recognized until ICU 55. To maintain common behavior across all supported ICU versions, check for "und" and replace with "root" before opening. Previously, the lack of support for "und" was dangerous, because versions 54 and older fall back to the environment when a locale is not found. If the user specified "und" for the language (which is expected and documented), it could not only resolve to the wrong collator, but it could unexpectedly change (which could lead to corrupt indexes). This effectively reverts commit d72900bded, which worked around the problem for the built-in "unicode" collation, and is no longer necessary. Discussion: https://postgr.es/m/60da0cecfb512a78b8666b31631a636215d8ce73.camel@j-davis.com Discussion: https://postgr.es/m/0c6fa66f2753217d2a40480a96bd2ccf023536a1.camel@j-davis.com Reviewed-by: Peter Eisentraut
* amcheck: Fix a few bugs in new update chain validation.Robert Haas2023-03-23
| | | | | | | | | | | | | | | | | | | | We shouldn't set successor[whatever] to an offset number that is less than FirstOffsetNumber or more than maxoff. We already avoided that for redirects, but not for CTID links. Allowing bad offset numbers into the successor[] array causes core dumps. We shouldn't use HeapTupleHeaderIsHotUpdated() because it checks stuff other than the status of the infomask2 bit HEAP_HOT_UPDATED. We only care about the status of that bit, not the other stuff that HeapTupleHeaderIsHotUpdated() checks. This mistake can cause verify_heapam() to report corruption when none is present. The first hunk of this patch was written by me. The other two were written by Andres Freund. This could probably do with more review before commit, but I'd like to try to get the buildfarm green again sooner rather than later. Discussion: http://postgr.es/m/20230322204552.s6cv3ybqkklhhybb@awork3.anarazel.de
* Add missing "-I." flag when building pg_bsd_indent.Tom Lane2023-03-23
| | | | | | This is evidently not required by most compilers, but buildfarm member fairywren is unhappy without it. It looks like the meson infrastructure has this right already.
* Minor comment improvements for compress_lz4Tomas Vondra2023-03-23
| | | | | | Author: Tomas Vondra Reviewed-by: Georgios Kokolatos, Justin Pryzby Discussion: https://postgr.es/m/33496f7c-3449-1426-d568-63f6bca2ac1f@gmail.com
* Unify buffer sizes in pg_dump compression APITomas Vondra2023-03-23
| | | | | | | | | | | | | | | | | | | | Prior to the introduction of the compression API in e9960732a9, pg_dump would use the ZLIB_IN_SIZE/ZLIB_OUT_SIZE to size input/output buffers. Commit 0da243fed0 introduced similar constants for LZ4, but while gzip defined both buffers to be 4kB, LZ4 used 4kB and 16kB without any clear reasoning why that's desirable. Furthermore, parts of the code unaware of which compression is used (e.g. pg_backup_directory.c) continued to use ZLIB_OUT_SIZE directly. Simplify by replacing the various constants with DEFAULT_IO_BUFFER_SIZE, set to 4kB. The compression implementations still have an option to use a custom value, but considering 4kB was fine for 20+ years, I find that unlikely (and we'd probably just increase the default buffer size). Author: Georgios Kokolatos Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/33496f7c-3449-1426-d568-63f6bca2ac1f@gmail.com
* Improve type handling in pg_dump's compress file APITomas Vondra2023-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After 0da243fed0 got committed, we've received a report about a compiler warning, related to the new LZ4File_gets() function: compress_lz4.c: In function 'LZ4File_gets': compress_lz4.c:492:19: warning: comparison of unsigned expression in '< 0' is always false [-Wtype-limits] 492 | if (dsize < 0) The reason is very simple - dsize is declared as size_t, which is an unsigned integer, and thus the check is pointless and we might fail to notice an error in some cases (or fail in a strange way a bit later). The warning could have been silenced by simply changing the type, but we realized the API mostly assumes all the libraries use the same types and report errors the same way (e.g. by returning 0 and/or negative value). But we can't make this assumption - the gzip/lz4 libraries already disagree on some of this, and even if they did a library added in the future might not. The right solution is to define what the API does, and translate the library-specific behavior in consistent way (so that the internal errors are not exposed to users of our compression API). So this adjusts the data types in a couple places, so that we don't miss library errors, and simplifies and unifies the error reporting to simply return true/false (instead of e.g. size_t). While at it, make sure LZ4File_open_write() does not clobber errno in case open_func() fails. Author: Georgios Kokolatos Reported-by: Alexander Lakhin Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/33496f7c-3449-1426-d568-63f6bca2ac1f@gmail.com
* Wrap ICU ucol_open().Jeff Davis2023-03-23
| | | | | | | | | | Hide details of supporting older ICU versions in a wrapper function. The current code only needs to handle icu_set_collation_attributes(), but a subsequent commit will add additional version-specific code. Discussion: https://postgr.es/m/7ee414ad-deb5-1144-8a0e-b34ae3b71cd5@enterprisedb.com Reviewed-by: Peter Eisentraut
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 21:23:05 +0000