summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2025-01-19Remove PrintBufferDescs() and PrintPinnedBufs().HEADmasterTom Lane
These have been #ifdef'd out for a long time, and in fact have been uncompilable since commit 48354581a of 2016-04-10. The fact that nobody noticed for so long demonstrates their lack of usefulness, so let's remove them rather than fix them. Author: Jacob Brazeal <[email protected]> Discussion: https://postgr.es/m/CA+COZaB+9CN_f63PPRoVhHjYmCwwmb_9CWLxqCJdMWDqs1a-JA@mail.gmail.com
2025-01-19Be clearer about when jsonapi's need_escapes is neededAndrew Dunstan
Most operations beyond pure json parsing need to set need_escapes to true to get access to field names and string scalars. Document this fact more explicitly. Slightly tweaked patch from: Author: Corey Huinker <[email protected]> Discussion: https://postgr.es/m/CADkLM=c49Vkfg2+A8ubSuEtaGEjuaKZXCA6SrXA8kdwHjx3uxQ@mail.gmail.com
2025-01-17Support PG_UNICODE_FAST locale in the builtin collation provider.Jeff Davis
The PG_UNICODE_FAST locale uses code point sort order (fast, memcmp-based) combined with Unicode character semantics. The character semantics are based on Unicode full case mapping. Full case mapping can map a single codepoint to multiple codepoints, such as "ß" uppercasing to "SS". Additionally, it handles context-sensitive mappings like the "final sigma", and it uses titlecase mappings such as "Dž" when titlecasing (rather than plain uppercase mappings). Importantly, the uppercasing of "ß" as "SS" is specifically mentioned by the SQL standard. In Postgres, UCS_BASIC uses plain ASCII semantics for case mapping and pattern matching, so if we changed it to use the PG_UNICODE_FAST locale, it would offer better compliance with the standard. For now, though, do not change the behavior of UCS_BASIC. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Reviewed-by: Peter Eisentraut, Daniel Verite
2025-01-17Support Unicode full case mapping and conversion.Jeff Davis
Generate tables from Unicode SpecialCasing.txt to support more sophisticated case mapping behavior: * support case mappings to multiple codepoints, such as "ß" uppercasing to "SS" * support conditional case mappings, such as the "final sigma" * support titlecase variants, such as "dž" uppercasing to "DŽ" but titlecasing to "Dž" Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Reviewed-by: Peter Eisentraut, Daniel Verite
2025-01-17vacuumdb: Fix comment for vacuum_one_database().Nathan Bossart
Since commit e0c2933a76, vacuum_one_database() always uses a catalog query to discover the tables to process, but this comment still notes the special case for which we used a catalog query before that commit. Let's just remove that note. Also, commit 7781f4e3e7 renamed the "tables" parameter to "objects" but missed updating this comment. This commit fixes that as well.
2025-01-17Add documentation about calling version-1 C functions from C.Tom Lane
This topic wasn't really covered before, so fill in some details. Author: Florents Tselai <[email protected]> Reviewed-by: Pavel Stehule <[email protected]> Reviewed-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected]
2025-01-17Fix parsing of qualified relation names in RETURNING.Dean Rasheed
Given a qualified refname, refnameNamespaceItem() will search for a matching namespace item by relation OID, rather than by name. Commit 80feb727c8 broke this by adding additional namespace items for OLD and NEW in the RETURNING list, which have the same relation OID, causing ambiguity. Fix this by ignoring these in the search, which is correct since they don't match the qualified relation name, and so there is no real ambiguity. Reported by Richard Guo. Discussion: https://postgr.es/m/CAMbWs49MBjWYWDROJ8MZ%3DY%2B4UgRQa10wzik1tWrD5yto9eoGXg%40mail.gmail.com
2025-01-17Speed up hex_encode with bytewise lookupJohn Naylor
Previously, hex_encode looked up each nibble of the input separately. We now use a larger lookup table containing the two-byte encoding of every possible input byte, resulting in a 1/3 reduction in encoding time. Reviewed by Tom Lane, Michael Paquier, Nathan Bossart, David Rowley Discussion: https://postgr.es/m/CANWCAZZvXuJMgqMN4u068Yqa19CEjS31tQKZp_qFFFbgYfaXqQ%40mail.gmail.com
2025-01-17Remove flex version checksPeter Eisentraut
Remove the flex version checks from configure and meson. The cutoff versions are all so ancient that this is no longer relevant, and what the actual cutoff should be is a bit fuzzy. This also removes the ancient behavior that configure would also accept a "lex" program if it is actuall flex. This aligns the check with meson in this respect. For future reference, as of this commit, these are relevant flex versions: - The hard required minimum is flex 2.5.34 as of commit b1ef48980dd, but this has not actually been tested. - Prior to this, the minimum enforced by configure/meson was flex 2.5.35, which is the oldest present in the buildfarm right now. - As of commit 6fdd5d95634, the oldest version that will compile without warnings due to flex-generated code is flex 2.5.36. - The oldest version that probably still has some practical relevance is flex 2.5.37, which ships with CentOS/RHEL 7. Discussion: https://www.postgresql.org/message-id/[email protected]
2025-01-17Add pg_nodiscard decorations to base64 functionsPeter Eisentraut
The result of pg_b64_encode() and pg_b64_decode() should be checked for errors. This attribute could detect mistakes such as those fixed in commit ff030ebe250 and d278541be42. Reviewed-by: Michael Paquier <[email protected]> Reviewed-by: Ranier Vilela <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CAEudQAq-3yHsSdWoOOaw%2BgAQYgPMpMGuB5pt2yCXgv-YuxG2Hg%40mail.gmail.com
2025-01-17Revert recent changes related to handling of 2PC files at recoveryMichael Paquier
This commit reverts 8f67f994e8ea (down to v13) and c3de0f9eed38 (down to v17), as these are proving to not be completely correct regarding two aspects: - In v17 and newer branches, c3de0f9eed38's check for epoch handling is incorrect, and does not correctly handle frozen epochs. A logic closer to widen_snapshot_xid() should be used. The 2PC code should try to integrate deeper with FullTransactionIds, 5a1dfde8334b being not enough. - In v13 and newer branches, 8f67f994e8ea is a workaround for the real issue, which is that we should not attempt CLOG lookups without reaching consistency. This exists since 728bd991c3c4, and this is reachable with ProcessTwoPhaseBuffer() called by restoreTwoPhaseData() at the beginning of recovery. Per discussion with Noah Misch. Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13
2025-01-17Remove redefinitions of SIG_* macros in win32_port.h.Nathan Bossart
It is not clear why these were originally added. One hypothesis is that an ancient version of MinGW didn't define them. In any case, they appear to now be superfluous, so let's remove them. If nothing else, the buildfarm might offer us clues to their origins. Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/Z4chOKfnthRH71mw%40nathan
2025-01-17Fix setrefs.c's failure to do expression processing on prune steps.Tom Lane
We should run the expression subtrees of PartitionedRelPruneInfo structs through fix_scan_expr. Failure to do so means that AlternativeSubPlans within those expressions won't be cleaned up properly, resulting in "unrecognized node type" errors since v14. It seems fairly likely that at least some of the other steps done by fix_scan_expr are important here as well, resulting in as-yet- undetected bugs. Therefore, I've chosen to back-patch this to all supported branches including v13, even though the known symptom doesn't manifest in v13. Per bug #18778 from Alexander Lakhin. Discussion: https://postgr.es/m/[email protected]
2025-01-16Add and use BitmapHeapScanDescData structMelanie Plageman
Move the several members of HeapScanDescData which are specific to Bitmap Heap Scans into a new struct, BitmapHeapScanDescData, which inherits from HeapScanDescData. This reduces the size of the HeapScanDescData for other types of scans and will allow us to add additional bitmap heap scan-specific members in the future without fear of bloating the HeapScanDescData. Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/c736f6aa-8b35-4e20-9621-62c7c82e2168%40vondra.me
2025-01-16Rework macro pgstat_is_ioop_tracked_in_bytes()Michael Paquier
As written, it was triggering a compilation warning for old versions of clang, as reported by buildfarm members ayu, batfish and demoiselle. Forcing a cast with "unsigned int" should fix the warning. While on it, the macro is moved to pgstat.h, closer to the declaration of IOOp, per suggestion from Tom Lane. Reported-by: Tom Lane Reviewed-by: Bertrand Drouvot, Tom Lane, Nazir Bilal Yavuz Discussion: https://postgr.es/m/[email protected]
2025-01-16Convert libpgport's pqsignal() to a void function.Nathan Bossart
The protections added by commit 3b00fdba9f introduced race conditions to this function that can lead to bogus return values. Since nobody seems to inspect the return value, this is of little consequence, but it would have been nice to convert it to a void function to avoid any possibility of a bogus return value. I originally thought that doing so would have required also modifying legacy-pqsignal.c's version of the function (which would've required an SONAME bump), but commit 9a45a89c38 gave legacy-pqsignal.c its own dedicated extern for pqsignal(), thereby decoupling it enough that libpgport's pqsignal() can be modified. This commit also adds an assertion for the return value of sigaction()/signal(). Since a failure most likely indicates a coding error, and nobody has ever bothered to check pqsignal()'s return value, it's probably not worth the effort to do anything fancier. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/Z4chOKfnthRH71mw%40nathan
2025-01-16Avoid calling pqsignal() with invalid signals on Windows frontends.Nathan Bossart
As noted by the comment at the top of port/pqsignal.c, Windows frontend programs can only use pqsignal() with the 6 signals required by C. Most places avoid using invalid signals via #ifndef WIN32, but initdb and pg_test_fsync check whether the signal itself is defined, which doesn't work because win32_port.h defines many extra signals for the signal emulation code. pg_regress seems to have missed the memo completely. These issues aren't causing any real problems today because nobody checks the return value of pqsignal(), but a follow-up commit will add some error checking. To fix, surround all frontend calls to pqsignal() that use signals that are invalid on Windows with #ifndef WIN32. We cannot simply skip defining the extra signals in win32_port.h for frontends because they are needed in places such as pgkill(). Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/Z4chOKfnthRH71mw%40nathan
2025-01-16Seek zone abbreviations in the IANA data before timezone_abbreviations.Tom Lane
If a time zone abbreviation used in datetime input is defined in the currently active timezone, use that definition in preference to looking in the timezone_abbreviations list. That allows us to correctly handle abbreviations that have different meanings in different timezones. Also, it eliminates an inconsistency between datetime input and datetime output: the non-ISO datestyles for timestamptz have always printed abbreviations taken from the IANA data, not from timezone_abbreviations. Before this fix, it was possible to demonstrate cases where casting a timestamp to text and back fails or changes the value significantly because of that inconsistency. While this change removes the ability to override the IANA data about an abbreviation known in the current zone, it's not clear that there's any real use-case for doing so. But it is clear that this makes life a lot easier for dealing with abbreviations that have conflicts across different time zones. Also update the pg_timezone_abbrevs view to report abbreviations that are recognized via the IANA data, and *not* report any timezone_abbreviations entries that are thereby overridden. Under the hood, there are now two SRFs, one that pulls the IANA data and one that pulls timezone_abbreviations entries. They're combined by logic in the view. This approach was useful for debugging (since the functions can be called on their own). While I don't intend to document the functions explicitly, they might be useful to call directly. Also improve DecodeTimezoneAbbrev's caching logic so that it can cache zone abbreviations found in the IANA data. Without that, this patch would have caused a noticeable degradation of the runtime of timestamptz_in. Per report from Aleksander Alekseev and additional investigation. Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=CO5XFMF4dvTGH+skzB--jNhqSQu5g@mail.gmail.com
2025-01-16Make pg_interpret_timezone_abbrev() check sp->defaulttype too.Tom Lane
This omission caused it to not recognize the furthest-back zone abbreviation when working with timezone data compiled with relatively recent zic (2018f or newer). Older versions of zic produced a dummy DST transition at the Big Bang, so that the oldest abbreviation could always be found in the sp->types[] array; but newer versions don't do that, so that we must examine defaulttype as well as the types[] array to be sure of seeing all the abbreviations. While this has been broken for six or so years, we'd managed not to notice for two reasons: (1) many platforms are still using ancient zic for compatibility reasons, so that the issue did not manifest in builds using --with-system-tzdata; (2) the oldest zone abbreviation is almost always "LMT", which we weren't supporting anyway (but an upcoming patch will accept that). While at it, update pg_next_dst_boundary() to use sp->defaulttype as the time type for non-DST zones and times before the oldest DST transition. The existing code there predates upstream's invention of the sp->defaulttype field, and its heuristic for finding the oldest time type has now been subsumed into the code that sets sp->defaulttype. Possibly this should be back-patched, but I'm not currently aware of any visible consequences of this bug in released branches. Per report from Aleksander Alekseev and additional investigation. Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=CO5XFMF4dvTGH+skzB--jNhqSQu5g@mail.gmail.com
2025-01-16Fix nbtree contradictory array element comment.Peter Geoghegan
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution.
2025-01-16Split ATExecValidateConstraint into reusable piecesÁlvaro Herrera
With this, we have separate functions to add validation requests to ALTER TABLE's phase 3 queue for check and foreign key constraints, which allows reusing them in future commits -- particularly this will allow us to perform validation of invalid foreign key constraints in partitioned tables. We could have let the check constraint code alone since we don't need to reuse that for anything at this point, but it seems cleaner and more consistent to do both at the same time. Author: Amul Sul <[email protected]> Discussion: https://postgr.es/m/CAAJ_b96Bp=-ZwihPPtuaNX=SrZ0U6ZsXD3+fgARO0JuKa8v2jQ@mail.gmail.com
2025-01-16Add OLD/NEW support to RETURNING in DML queries.Dean Rasheed
This allows the RETURNING list of INSERT/UPDATE/DELETE/MERGE queries to explicitly return old and new values by using the special aliases "old" and "new", which are automatically added to the query (if not already defined) while parsing its RETURNING list, allowing things like: RETURNING old.colname, new.colname, ... RETURNING old.*, new.* Additionally, a new syntax is supported, allowing the names "old" and "new" to be changed to user-supplied alias names, e.g.: RETURNING WITH (OLD AS o, NEW AS n) o.colname, n.colname, ... This is useful when the names "old" and "new" are already defined, such as inside trigger functions, allowing backwards compatibility to be maintained -- the interpretation of any existing queries that happen to already refer to relations called "old" or "new", or use those as aliases for other relations, is not changed. For an INSERT, old values will generally be NULL, and for a DELETE, new values will generally be NULL, but that may change for an INSERT with an ON CONFLICT ... DO UPDATE clause, or if a query rewrite rule changes the command type. Therefore, we put no restrictions on the use of old and new in any DML queries. Dean Rasheed, reviewed by Jian He and Jeff Davis. Discussion: https://postgr.es/m/CAEZATCWx0J0-v=Qjc6gXzR=KtsdvAE7Ow=D=mu50AgOe+pvisQ@mail.gmail.com
2025-01-16Remove dead codePeter Eisentraut
As of commit 9895b35cb88, AlterDomainAddConstraint() can only be called with constraints of type CONSTR_CHECK and CONSTR_NOTNULL. So all the code to check for and reject other constraint type values is dead and can be removed. Author: jian he <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CACJufxHitd5LGLBSSAPShhtDWxT0ViVKTHinkYW-skBX93TcpA@mail.gmail.com
2025-01-16refactor: split ATExecAlterConstrRecurse()Peter Eisentraut
This splits out a couple of subroutines from ATExecAlterConstrRecurse(). This makes the main function a bit smaller, and a future patch (NOT ENFORCED foreign-key constraints) will also want to call some of the pieces separately. Author: Amul Sul <[email protected]> Reviewed-by: jian he <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b962c5AcYW9KUt_R_ER5qs3fUGbe4az-SP-vuwPS-w-AGA%40mail.gmail.com
2025-01-16Fix error handling of pg_b64_decode()Peter Eisentraut
Fix for commit 761c79508e7. The previous error handling logic was not quite correct. Discussion: https://www.postgresql.org/message-id/flat/CAEudQAq-3yHsSdWoOOaw%2BgAQYgPMpMGuB5pt2yCXgv-YuxG2Hg%40mail.gmail.com
2025-01-16Move routines to manipulate WAL into PostgreSQL::Test::ClusterMichael Paquier
These facilities were originally in the recovery TAP test 039_end_of_wal.pl. A follow-up bug fix with a TAP test doing similar WAL manipulations requires them, and all these had better not be duplicated due to their complexity. The routine names are tweaked to use "wal" more consistently, similarly to the existing "advance_wal". In v14 and v13, the new routines are moved to PostgresNode.pm. 039_end_of_wal.pl is updated to use the refactored routines, without changing its coverage. Reviewed-by: Alexander Kukushkin Discussion: https://postgr.es/m/CAFh8B=mozC+e1wGJq0H=0O65goZju+6ab5AU7DEWCSUA2OtwDg@mail.gmail.com Backpatch-through: 13
2025-01-15Fix cpluspluscheck for "Change gist stratnum function to use CompareType"Peter Eisentraut
Commit 630f9a43cec introduced an enum forward declaration, which doesn't work in C++. To fix, just include the header file to get the type.
2025-01-15Add more general summary to vacuumlazy.cMelanie Plageman
Add more comments at the top of vacuumlazy.c on heap relation vacuuming implementation. Previously vacuumlazy.c only had details related to dead TID storage. This commit adds a more general summary to help future developers understand the heap relation vacuum design and implementation at a high level. Reviewed-by: Alena Rybakina, Robert Haas, Andres Freund, Bilal Yavuz Discussion: https://postgr.es/m/flat/CAAKRu_ZF_KCzZuOrPrOqjGVe8iRVWEAJSpzMgRQs%3D5-v84cXUg%40mail.gmail.com
2025-01-15Add a bit of documentation related to IWYUPeter Eisentraut
Add some basic information about IWYU to src/tools/pginclude/README. Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15IWYU pragmas for catalog headersPeter Eisentraut
Add "IWYU pragma: export" annotations in each catalog header file so that, for instance, including "catalog/pg_aggregate.h" is considered acceptable in place of "catalog/pg_aggregate_d.h". This is very common and it seems better to silence IWYU about it than trying to fix this up. Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15IWYU widely useful pragmasPeter Eisentraut
Add various widely useful "IWYU pragma" annotations, such as - Common header files such as c.h, postgres.h should be "always_keep". - System headers included in c.h, postgres.h etc. should be considered "export". - Some portability headers such as getopt_long.h should be "always_keep", so they are not considered superfluous on some platforms. - Certain system headers included from portability headers should be considered "export" because the purpose of the portability header is to wrap them. - Superfluous includes marked as "for backward compatibility" get a formal IWYU annotation. - Generated header included in utils/syscache.h is marked exported. This is a very commonly used include and this avoids lots of complaints. Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15postgres_fdw: SCRAM authentication pass-throughPeter Eisentraut
This enables SCRAM authentication for postgres_fdw when connecting to a foreign server without having to store a plain-text password on user mapping options. This is done by saving the SCRAM ClientKey and ServeryKey from the client authentication and using those instead of the plain-text password for the server-side SCRAM exchange. The new foreign-server or user-mapping option "use_scram_passthrough" enables this. Co-authored-by: Matheus Alcantara <[email protected]> Co-authored-by: Peter Eisentraut <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15Downgrade error in object_aclmask_ext() to internalPeter Eisentraut
The "does not exist" error in object_aclmask_ext() was written as ereport(), suggesting that it is user-facing. This is problematic: get_object_class_descr() is meant to be for internal errors only and does not support translation. For the has_xxx_privilege functions, the error has not been user-facing since commit 403ac226ddd. The remaining users are pg_database_size() and pg_tablespace_size(). The call stack here is pretty deep and this dependency is not obvious. Here we can put in an explicit existence check with a bespoke error message early in the function. Then we can downgrade the error in object_aclmask_ext() to a normal "cache lookup failed" internal error. Reviewed-by: Alvaro Herrera <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15Downgrade errors in object_ownercheck() to internalPeter Eisentraut
The "does not exist" errors in object_ownership() were written as ereport(), suggesting that they are user-facing. But no code path except one can reach this function without first checking that the object exists. If this were actually a user-facing error message, then there would be some problems: get_object_class_descr() is meant to be for internal errors only and does not support translation. The one case that can reach this without first checking the object existence is from be_lo_unlink(). (This makes some sense since large objects are referred to by their OID directly.) In this one case, we can add a line of code to check the object existence explicitly, consistent with other LO code. For the rest, downgrade the error messages to elog()s. The new message wordings are the same as in DropObjectById(). Reviewed-by: Alvaro Herrera <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15Drop warning-free support for Flex 2.5.35Peter Eisentraut
This removes all the various workarounds for avoiding compiler warnings with Flex 2.5.35. Several recent patches have added additional warnings that would either need to be fixed along the lines of the existing workarounds, or we decide to no longer care about this, which we do here. Flex 2.5.35 is extremely outdated, and you can't even download it anymore from any of the Flex project sites, so it's nearly impossible to support. After this, using Flex 2.5.35 will still work, but the generated code will produce numerous compiler warnings. Reviewed-by: Tom Lane <[email protected]> Discussion: https://www.postgresql.org/message-id/[email protected]
2025-01-15Change gist stratnum function to use CompareTypePeter Eisentraut
This changes commit 7406ab623fe in that the gist strategy number mapping support function is changed to use the CompareType enum as input, instead of the "well-known" RT*StrategyNumber strategy numbers. This is a bit cleaner, since you are not dealing with two sets of strategy numbers. Also, this will enable us to subsume this system into a more general system of using CompareType to define operator semantics across index methods. Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-15Rename RowCompareType to CompareTypePeter Eisentraut
RowCompareType served as a way to describe the fundamental meaning of an operator, notionally independent of an operator class (although so far this was only really supported for btrees). Its original purpose was for use inside RowCompareExpr, and it has also found some small use outside, such as for get_op_btree_interpretation(). We want to expand this now, as a more general way to describe operator semantics for other index access methods, including gist (to improve GistTranslateStratnum()) and others not written yet. To avoid future confusion, we rename the type to CompareType and the symbols from ROWCOMPARE_XXX to COMPARE_XXX to reflect their more general purpose. Reviewed-by: Mark Dilger <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]
2025-01-14Avoid symbol collisions between pqsignal.c and legacy-pqsignal.c.Tom Lane
In the name of ABI stability (that is, to avoid a library major version bump for libpq), libpq still exports a version of pqsignal() that we no longer want to use ourselves. However, since that has the same link name as the function exported by src/port/pqsignal.c, there is a link ordering dependency determining which version will actually get used by code that uses libpq as well as libpgport.a. It now emerges that the wrong version has been used by pgbench and psql since commit 06843df4a rearranged their link commands. This can result in odd failures in pgbench with the -T switch, since its SIGALRM handler will now not be marked SA_RESTART. psql may have some edge-case problems in \watch, too. Since we don't want to depend on link ordering effects anymore, let's fix this in the same spirit as b6c7cfac8: use macros to change the actual link names of the competing functions. We cannot change legacy-pqsignal.c's exported name of course, so the victim has to be src/port/pqsignal.c. In master, rename its exported name to be pqsignal_fe in frontend or pqsignal_be in backend. (We could perhaps have gotten away with using the same symbol in both cases, but since the FE and BE versions now work a little differently, it seems advisable to use different names.) In back branches, rename to pqsignal_fe in frontend but keep it as pqsignal in backend. The frontend change could affect third-party code that is calling pqsignal from libpgport.a or libpgport_shlib.a, but only if the code is compiled against port.h from a different minor release than libpgport. Since we don't support using libpgport as a shared library, it seems unlikely that there will be such a problem. I left the backend symbol unchanged to avoid an ABI break for extensions. This means that the link ordering hazard still exists for any extension that links against libpq. However, none of our own extensions use both pqsignal() and libpq, and we're not making things any worse for third-party extensions that do. Report from Andy Fan, diagnosis by Fujii Masao, patch by me. Back-patch to all supported branches, as 06843df4a was. Discussion: https://postgr.es/m/[email protected]
2025-01-14Synchronize guc_tables.c categories with vacuum docs categoriesMelanie Plageman
ca9c6a5680d consolidated most of the vacuum-related GUCs' documentation into a new subsection. af2317652d5daf8b then enforced this order in postgresql.conf.sample. This commit reorganizes the GUC groups in guc_tables.c/h to match the updated ordering in the docs. Reported-by: Álvaro Herrera Reviewed-by: Álvaro Herrera, Alena Rybakina Discussion: https://postgr.es/m/202501132046.m4mcvxxswznu%40alvherre.pgsql
2025-01-14psql: Add option to use expanded mode to all list commands.Dean Rasheed
This allows "x" to be appended to any psql list-like meta-command, forcing its output to be displayed in expanded mode. This improves readability in cases where the output is very wide. For example, "\dfx+" (or equivalently "\df+x") will produce a list of functions, with additional details, in expanded mode. This works with all \d* meta-commands, plus \l, \z, and \lo_list, with the one exception that the expanded mode option "x" cannot be appended to "\d" by itself, since "\dx" already means something else. Dean Rasheed, reviewed by Greg Sabino Mullane. Discussion: https://postgr.es/m/CAEZATCVXJk3KsmCncf7PAVbxdDAUDm3QzDgGT7mBYySWikuOYw@mail.gmail.com
2025-01-14ecpg: Restore detection of unsupported COPY FROM STDIN.Fujii Masao
The ecpg command includes code to warn about unsupported COPY FROM STDIN statements in input files. However, since commit 3d009e45bd, this functionality has been broken due to a bug introduced in that commit, causing ecpg to fail to detect the statement. This commit resolves the issue, restoring ecpg's ability to detect COPY FROM STDIN and issue a warning as intended. Back-patch to all supported versions. Author: Ryo Kanbayashi Reviewed-by: Hayato Kuroda, Tom Lane Discussion: https://postgr.es/m/CANOn0Ez_t5uDCUEV8c1YORMisJiU5wu681eEVZzgKwOeiKhkqQ@mail.gmail.com
2025-01-14Consistently spell "leakproof" without a hyphen.Dean Rasheed
The overwhelming majority of places already did this, but a small handful of places had a hyphen. Yugo Nagata. Discussion: https://postgr.es/m/CAEZATCXnnuORE2BoGwHw2zbtVvsPOLhbfVmEk9GxRzK%2Bx3OW-Q%40mail.gmail.com
2025-01-14psql: Add leakproof indicator to \df+, \do+, \dAo+, and \dC+ output.Dean Rasheed
This allows users to determine whether particular functions are leakproof, and whether the underlying functions used by operators and casts are leakproof. This is useful to determine whether indexes can be used in queries on security barrier views or tables with row-level security policies. Yugo Nagata, reviewed by Erik Wienhold and Dean Rasheed. Discussion: https://postgr.es/m/20240701220817.483f9b645b95611f8b1f65da%40sranhm.sraoss.co.jp
2025-01-14Fix catcache invalidation of a list entry that's being builtHeikki Linnakangas
If a new catalog tuple is inserted that belongs to a catcache list entry, and cache invalidation happens while the list entry is being built, the list entry might miss the newly inserted tuple. To fix, change the way we detect concurrent invalidations while a catcache entry is being built. Keep a stack of entries that are being built, and apply cache invalidation to those entries in addition to the real catcache entries. This is similar to the in-progress list in relcache.c. Back-patch to all supported versions. Reviewed-by: Noah Misch Discussion: https://www.postgresql.org/message-id/[email protected]
2025-01-14Bump PGSTAT_FILE_FORMAT_IDMichael Paquier
Oversight in f92c854cf406, that has changed the definition of PgStat_BktypeIO, impacting PgStat_IO which is the on-disk data for IO pgstats data.
2025-01-14Fix potential integer overflow in bringetbitmap()Michael Paquier
This function expects an "int64" as result and stores the number of pages to add to the index scan bitmap as an "int", multiplying its final result by 10. For a relation large enough, this can theoretically overflow if counting more than (INT32_MAX / 10) pages, knowing that the number of pages is upper-bounded by MaxBlockNumber. To avoid the overflow, this commit redefines "totalpages", used to calculate the result, to be an "int64" rather than an "int". Reported-by: Evgeniy Gorbanyov Author: James Hunter Discussion: https://www.postgresql.org/message-id/[email protected] Backpatch-through: 13
2025-01-14Move information about pgstats kinds into its own header pgstat_kind.hMichael Paquier
This includes all the definitions for the various PGSTAT_KIND_* values, the range allowed for custom stats kinds and some macros related all that. One use-case behind this split is the possibility to use this information for frontend tools, without having to rely on pgstat.h and a backend footprint. Author: Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/[email protected]
2025-01-14Remove assertion in pgstat_count_io_op()Michael Paquier
An equivalent check is done with pgstat_is_ioop_tracked_in_bytes(), so there is no need for this extra one. Small cleanup that should have been included in f92c854cf406. Author: Nazir Bilal Yavuz Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/CAN55FZ0oqxBaaHAEsj=xFqkzE3n5P=3RA1V_igXwL-RV7QRzyw@mail.gmail.com
2025-01-14Make pg_stat_io count IOs as bytes instead of blocks for some operationsMichael Paquier
Currently in pg_stat_io view, IOs are counted as blocks of size BLCKSZ. There are two limitations with this design: * The actual number of I/O requests sent to the kernel is lower because I/O requests may be merged before being sent. Additionally, it gives the impression that all I/Os are done in block size, which shadows the benefits of merging I/O requests. * Some patches are under work to extend pg_stat_io for the tracking of operations that may not be linked to the block size. For example, WAL read IOs are done in variable bytes and it is not possible to correctly show these IOs in pg_stat_io view, and we want to keep all this data in a single system view rather than spread it across multiple relations to ease monitoring. WaitReadBuffers() can now be tracked as a single read operation worth N blocks. Same for ExtendBufferedRelShared() and ExtendBufferedRelLocal() for extensions. Three columns are added to pg_stat_io for reads, writes and extensions for the byte calculations. op_bytes, which was always hardcoded to BLCKSZ, is removed. IO backend statistics are updated to reflect these changes. Bump catalog version. Author: Nazir Bilal Yavuz Reviewed-by: Bertrand Drouvot, Melanie Plageman Discussion: https://postgr.es/m/CAN55FZ0oqxBaaHAEsj=xFqkzE3n5P=3RA1V_igXwL-RV7QRzyw@mail.gmail.com
2025-01-13Revert "TupleHashTable: store additional data along with tuple."Jeff Davis
This reverts commit e0ece2a981ee9068f50c4423e303836c2585eb02 due to performance regressions. Reported-by: David Rowley