aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Update time zone data files to tzdata release 2025a.Tom Lane2025-01-20
| | | | | | | DST law changes in Paraguay. Historical corrections for the Philippines. Backpatch-through: 13
* Avoid using timezone Asia/Manila in regression tests.Tom Lane2025-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | The freshly-released 2025a version of tzdata has a refined estimate for the longitude of Manila, changing their value for LMT in pre-standardized-timezone days. This changes the output of one of our test cases. Since we need to be able to run with system tzdata files that may or may not contain this update, we'd better stop making that specific test. I switched it to use Asia/Singapore, which has a roughly similar UTC offset. That LMT value hasn't changed in tzdb since 2003, so we can hope that it's well established. I also noticed that this set of make_timestamptz tests only exercises zones east of Greenwich, which seems rather sad, and was not the original intent AFAICS. (We've already changed these tests once to stabilize their results across tzdata updates, cf 66b737cd9; it looks like I failed to consider the UTC-offset-sign aspect then.) To improve that, add a test with Pacific/Honolulu. That LMT offset is also quite old in tzdb, so we'll cross our fingers that it doesn't get improved. Reported-by: Christoph Berg <cb@df7cb.de> Discussion: https://postgr.es/m/Z46inkznCxesvDEb@msg.df7cb.de Backpatch-through: 13
* Improve generated_stored testPeter Eisentraut2025-01-20
| | | | | | | | | | It makes more sense to put the catalog sanity check at the end of the test rather than at the beginning, so that it can also check whatever the tests did rather than just whatever happened before the tests. Suggested-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/a368248e-69e4-40be-9c07-6c3b5880b0a6@eisentraut.org
* Add some more use of Page/PageData rather than char *Peter Eisentraut2025-01-20
| | | | Discussion: https://www.postgresql.org/message-id/flat/692ee0da-49da-4d32-8dca-da224cc2800e@eisentraut.org
* Add const qualifiers to bufpage.hPeter Eisentraut2025-01-20
| | | | | | | | | | This makes use of the new PageData type. PageGetSpecialPointer() had to be turned back into a macro, because it is used in a way that sometimes it takes const and returns const and sometimes takes non-const and returns non-const. Discussion: https://www.postgresql.org/message-id/flat/692ee0da-49da-4d32-8dca-da224cc2800e@eisentraut.org
* Add PageData C typePeter Eisentraut2025-01-20
| | | | | | | | | | This adds the C type PageData and makes the existing type Page a pointer to it. This follows the usual PostgreSQL C type naming scheme of Foo/FooData pairs. (Prior to commit ddbba3aac86, PageData existed as an unrelated type.) The type definitions are compatible, so this doesn't change anything except some of the naming. Discussion: https://www.postgresql.org/message-id/flat/692ee0da-49da-4d32-8dca-da224cc2800e@eisentraut.org
* Fix latch event policy that hid socket events.Thomas Munro2025-01-20
| | | | | | | | | | | | | | | | | | | | | If a WaitEventSetWait() caller asks for multiple events, an already set latch would previously prevent other events from being reported at the same time. Now, we'll also poll the kernel for other events that would fit in the caller's output buffer with a zero wait time. This policy change doesn't affect callers that ask for only one event. The main caller affected is the postmaster. If its latch is set extremely frequently by backends launching workers and workers exiting, we don't want it to handle only those jobs and ignore incoming client connections. Back-patch to 16 where the postmaster began using the API. The fast-return policy changed here is older than that, but doesn't cause any known problems in earlier releases. Reported-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://postgr.es/m/Z1n5UpAiGDmFcMmd%40nathan
* Fix header check for continuation records where standbys could be stuckMichael Paquier2025-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | XLogPageRead() checks immediately for an invalid WAL record header on a standby, to be able to handle the case of continuation records that need to be read across two different sources. As written, the check was too generic, applying to any target LSN. Based on an analysis by Kyotaro Horiguchi, what really matters is to make sure that the page header is checked when attempting to read a LSN at the boundary of a segment, to handle the case of a continuation record that spawns across multiple pages when dealing with multiple segments, as WAL receivers are spawned they request WAL from the beginning of a segment. This fix has been proposed by Kyotaro Horiguchi. This could cause standbys to loop infinitely when dealing with a continuation record during a timeline jump, in the case where the contents of the record in the follow-up page are invalid. Some regression tests are added to check such scenarios, able to reproduce the original problem. In the test, the contents of a continuation record are overwritten with junk zeros on its follow-up page, and replayed on standbys. This is inspired by 039_end_of_wal.pl, and is enough to show how standbys should react on promotion by not being stuck. Without the fix, the test would fail with a timeout. The test to reproduce the problem has been written by Alexander Kukushkin. The original check has been introduced in 066871980183, for a similar problem. Author: Kyotaro Horiguchi, Alexander Kukushkin Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAFh8B=mozC+e1wGJq0H=0O65goZju+6ab5AU7DEWCSUA2OtwDg@mail.gmail.com Backpatch-through: 13
* Remove PrintBufferDescs() and PrintPinnedBufs().Tom Lane2025-01-19
| | | | | | | | | | 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 <jacob.brazeal@gmail.com> Discussion: https://postgr.es/m/CA+COZaB+9CN_f63PPRoVhHjYmCwwmb_9CWLxqCJdMWDqs1a-JA@mail.gmail.com
* Be clearer about when jsonapi's need_escapes is neededAndrew Dunstan2025-01-19
| | | | | | | | | | | | 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 <corey.huinker@gmail.com> Discussion: https://postgr.es/m/CADkLM=c49Vkfg2+A8ubSuEtaGEjuaKZXCA6SrXA8kdwHjx3uxQ@mail.gmail.com
* Support PG_UNICODE_FAST locale in the builtin collation provider.Jeff Davis2025-01-17
| | | | | | | | | | | | | | | | | | | | | | 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/ddfd67928818f138f51635712529bc5e1d25e4e7.camel@j-davis.com Discussion: https://postgr.es/m/27bb0e52-801d-4f73-a0a4-02cfdd4a9ada@eisentraut.org Reviewed-by: Peter Eisentraut, Daniel Verite
* Support Unicode full case mapping and conversion.Jeff Davis2025-01-17
| | | | | | | | | | | | | | | 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/ddfd67928818f138f51635712529bc5e1d25e4e7.camel@j-davis.com Discussion: https://postgr.es/m/27bb0e52-801d-4f73-a0a4-02cfdd4a9ada@eisentraut.org Reviewed-by: Peter Eisentraut, Daniel Verite
* vacuumdb: Fix comment for vacuum_one_database().Nathan Bossart2025-01-17
| | | | | | | | | | 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.
* Add documentation about calling version-1 C functions from C.Tom Lane2025-01-17
| | | | | | | | | This topic wasn't really covered before, so fill in some details. Author: Florents Tselai <florents.tselai@gmail.com> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/90853055-5BBD-493D-91E5-721677C7C59B@gmail.com
* Fix parsing of qualified relation names in RETURNING.Dean Rasheed2025-01-17
| | | | | | | | | | | | | | 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
* Speed up hex_encode with bytewise lookupJohn Naylor2025-01-17
| | | | | | | | | | | 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
* Remove flex version checksPeter Eisentraut2025-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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/1a204ccd-7ae6-478c-a431-407b5c48ccc6@eisentraut.org
* Add pg_nodiscard decorations to base64 functionsPeter Eisentraut2025-01-17
| | | | | | | | | | 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 <michael@paquier.xyz> Reviewed-by: Ranier Vilela <ranier.vf@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAEudQAq-3yHsSdWoOOaw%2BgAQYgPMpMGuB5pt2yCXgv-YuxG2Hg%40mail.gmail.com
* Revert recent changes related to handling of 2PC files at recoveryMichael Paquier2025-01-17
| | | | | | | | | | | | | | | | | | | | 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/20250116010051.f3.nmisch@google.com Backpatch-through: 13
* Remove redefinitions of SIG_* macros in win32_port.h.Nathan Bossart2025-01-16
| | | | | | | | | | 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
* Fix setrefs.c's failure to do expression processing on prune steps.Tom Lane2025-01-16
| | | | | | | | | | | | | | | | | 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/18778-24cd399df6c806af@postgresql.org
* Add and use BitmapHeapScanDescData structMelanie Plageman2025-01-16
| | | | | | | | | | | | | 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
* Rework macro pgstat_is_ioop_tracked_in_bytes()Michael Paquier2025-01-17
| | | | | | | | | | | | | 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/1272824.1736961543@sss.pgh.pa.us
* Convert libpgport's pqsignal() to a void function.Nathan Bossart2025-01-16
| | | | | | | | | | | | | | | | | | | | | | 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
* Avoid calling pqsignal() with invalid signals on Windows frontends.Nathan Bossart2025-01-16
| | | | | | | | | | | | | | | | | | | | 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
* Seek zone abbreviations in the IANA data before timezone_abbreviations.Tom Lane2025-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make pg_interpret_timezone_abbrev() check sp->defaulttype too.Tom Lane2025-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix nbtree contradictory array element comment.Peter Geoghegan2025-01-16
| | | | | Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution.
* Split ATExecValidateConstraint into reusable piecesÁlvaro Herrera2025-01-16
| | | | | | | | | | | | | | | 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 <sulamul@gmail.com> Discussion: https://postgr.es/m/CAAJ_b96Bp=-ZwihPPtuaNX=SrZ0U6ZsXD3+fgARO0JuKa8v2jQ@mail.gmail.com
* Add OLD/NEW support to RETURNING in DML queries.Dean Rasheed2025-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove dead codePeter Eisentraut2025-01-16
| | | | | | | | | | 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 <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CACJufxHitd5LGLBSSAPShhtDWxT0ViVKTHinkYW-skBX93TcpA@mail.gmail.com
* refactor: split ATExecAlterConstrRecurse()Peter Eisentraut2025-01-16
| | | | | | | | | | | 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 <amul.sul@enterprisedb.com> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b962c5AcYW9KUt_R_ER5qs3fUGbe4az-SP-vuwPS-w-AGA%40mail.gmail.com
* Fix error handling of pg_b64_decode()Peter Eisentraut2025-01-16
| | | | | | | 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
* Move routines to manipulate WAL into PostgreSQL::Test::ClusterMichael Paquier2025-01-16
| | | | | | | | | | | | | | | | 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
* Fix cpluspluscheck for "Change gist stratnum function to use CompareType"Peter Eisentraut2025-01-15
| | | | | | Commit 630f9a43cec introduced an enum forward declaration, which doesn't work in C++. To fix, just include the header file to get the type.
* Add more general summary to vacuumlazy.cMelanie Plageman2025-01-15
| | | | | | | | | | | | | 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
* Add a bit of documentation related to IWYUPeter Eisentraut2025-01-15
| | | | | | Add some basic information about IWYU to src/tools/pginclude/README. Discussion: https://www.postgresql.org/message-id/flat/9395d484-eff4-47c2-b276-8e228526c8ae@eisentraut.org
* IWYU pragmas for catalog headersPeter Eisentraut2025-01-15
| | | | | | | | | | 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/9395d484-eff4-47c2-b276-8e228526c8ae@eisentraut.org
* IWYU widely useful pragmasPeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/9395d484-eff4-47c2-b276-8e228526c8ae@eisentraut.org
* postgres_fdw: SCRAM authentication pass-throughPeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | 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 <mths.dev@pm.me> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/flat/27b29a35-9b96-46a9-bc1a-914140869dac@gmail.com
* Downgrade error in object_aclmask_ext() to internalPeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | | | | | | 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 <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/flat/da2f8942-be6d-48d0-ac1c-a053370a6b1f@eisentraut.org
* Downgrade errors in object_ownercheck() to internalPeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | | | | | | | 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 <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/flat/da2f8942-be6d-48d0-ac1c-a053370a6b1f@eisentraut.org
* Drop warning-free support for Flex 2.5.35Peter Eisentraut2025-01-15
| | | | | | | | | | | | | | | | | | 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 <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/1a204ccd-7ae6-478c-a431-407b5c48ccc6@eisentraut.org
* Change gist stratnum function to use CompareTypePeter Eisentraut2025-01-15
| | | | | | | | | | | | | 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/E72EAA49-354D-4C2E-8EB9-255197F55330@enterprisedb.com
* Rename RowCompareType to CompareTypePeter Eisentraut2025-01-15
| | | | | | | | | | | | | | | | | 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 <mark.dilger@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/E72EAA49-354D-4C2E-8EB9-255197F55330@enterprisedb.com
* Avoid symbol collisions between pqsignal.c and legacy-pqsignal.c.Tom Lane2025-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/87msfz5qv2.fsf@163.com
* Synchronize guc_tables.c categories with vacuum docs categoriesMelanie Plageman2025-01-14
| | | | | | | | | | | 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
* psql: Add option to use expanded mode to all list commands.Dean Rasheed2025-01-14
| | | | | | | | | | | | | | | | 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
* ecpg: Restore detection of unsupported COPY FROM STDIN.Fujii Masao2025-01-15
| | | | | | | | | | | | | | | | 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
* Consistently spell "leakproof" without a hyphen.Dean Rasheed2025-01-14
| | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-02 04:13:15 +0000