summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix incorrect partition pruning logic for boolean partitioned tablesDavid Rowley2023-04-143-31/+288
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The partition pruning logic assumed that "b IS NOT true" was exactly the same as "b IS FALSE". This is not the case when considering NULL values. Fix this so we correctly include any partition which could hold NULL values for the NOT case. Additionally, this fixes a bug in the partition pruning code which handles partitioned tables partitioned like ((NOT boolcol)). This is a seemingly unlikely schema design, and it was untested and also broken. Here we add tests for the ((NOT boolcol)) case and insert some actual data into those tables and verify we do get the correct rows back when running queries. I've also adjusted the existing boolpart tests to include some data and verify we get the correct results too. Both the bugs being fixed here could lead to incorrect query results with fewer rows being returned than expected. No additional rows could have been returned accidentally. In passing, remove needless ternary expression. It's more simple just to pass !is_not_clause to makeBoolConst(). It makes sense to do this so the code is consistent with the bug fix in the "else if" condition just below. David Kimura did submit a patch to fix the first of the issues here, but that's not what's being committed here. Reported-by: David Kimura Reviewed-by: Richard Guo, David Kimura Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com Backpatch-through: 11, all supported versions
* doc: Fix some grammar for logical decoding description and functionsMichael Paquier2023-04-143-13/+15
| | | | | | | | | This documentation is has been added for the support of logical decoding on standbys. Some markups were missing, hence add some where required. Author: Thom Brown Reviewed-by: Justin Pryzby, Daniel Gustafsson Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
* Fix PHJ match bit initialization.Thomas Munro2023-04-143-1/+65
| | | | | | | | | | | | | | | | | Hash join tuples reuse the HOT status bit to indicate match status during hash join execution. Correct reuse requires clearing the bit in all tuples. Serial hash join and parallel multi-batch hash join do so upon inserting the tuple into the hashtable. Single batch parallel hash join and batch 0 of unexpected multi-batch hash joins forgot to do this. It hadn't come up before because hashtable tuple match bits are only used for right and full outer joins and parallel ROJ and FOJ were unsupported. 11c2d6fdf5 introduced support for parallel ROJ/FOJ but neglected to ensure the match bits were reset. Author: Melanie Plageman <melanieplageman@gmail.com> Reported-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/flat/CAMbWs48Nde1Mv%3DBJv6_vXmRKHMuHZm2Q_g4F6Z3_pn%2B3EV6BGQ%40mail.gmail.com
* Remove code in charge of freeing regexps generation by Lab.cMichael Paquier2023-04-141-67/+5
| | | | | | | | | | | | | | | | | | | | | | | | | bea3d7e has redesigned the regexp engine so as all the allocations go through palloc() with a dedicated memory context. hba.c had to cope with the past memory management logic by going through all the HBA and ident lines generated, then directly free all the regexps found in AuthTokens to ensure that no leaks would happen. Such leaks could happen for example in the postmaster after a SIGHUP, in the event of an HBA and/or ident reload failure where all the new content parsed must be discarded, including all the regexps that may have been compiled. Now that regexps are palloc()'d in their own memory context, MemoryContextDelete() is enough to ensure that all the compiled regexps are properly gone. Simplifying this logic in hba.c has the effect to only remove code. Most of it is new in v16, except the part for regexps compiled in ident entries for the system username, so doing this cleanup now rather than when v17 opens for business will reduce future diffs with the upcoming REL_16_STABLE. Some comments were incorrect since bea3d7e, now fixed to reflect the reality. Reviewed-by: Bertrand Drouvot, Álvaro Herrera Discussion: https://postgr.es/m/ZDdJ289Ky2qEj4h+@paquier.xyz
* Remove old GUC name mapping for "force_parallel_mode"David Rowley2023-04-141-1/+0
| | | | | | | | | | | | | | | | This GUC was renamed to debug_parallel_query in 5352ca22e. That commit added an entry into map_old_guc_names[] to allow the old name still to work. That was done to allow a transition time where the buildfarm configs could be swapped over to use debug_parallel_query instead. That work is now complete. Here we remove the old name with the intention of breaking any user code which is using force_parallel_query. As mentioned in the commit message for 5352ca22e, it appeared many users were misled into thinking that setting this GUC was doing something useful for them to make queries run more quickly. Discussion: https://postgr.es/m/CAApHDvoR7EOz7Tvyzrd18FO-Dw2Cp4Uyq25TEWguK+XyCJtzOw@mail.gmail.com
* Update Unicode data to CLDR 43Peter Eisentraut2023-04-131-1/+1
| | | | No actual changes result.
* Harmonize some more function parameter names.Peter Geoghegan2023-04-1311-17/+17
| | | | | | | | | | | | | | Make sure that function declarations use names that exactly match the corresponding names from function definitions in a few places. These inconsistencies were all introduced relatively recently, after the code base had parameter name mismatches fixed in bulk (see commits starting with commits 4274dc22 and 035ce1fe). pg_bsd_indent still has a couple of similar inconsistencies, which I (pgeoghegan) have left untouched for now. Like all earlier commits that cleaned up function parameter names, this commit was written with help from clang-tidy.
* Explicitly require MIT Kerberos for GSSAPIStephen Frost2023-04-137-15/+57
| | | | | | | | | | WHen building with GSSAPI support, explicitly require MIT Kerberos and check for gssapi_ext.h in configure.ac and meson.build. Also add documentation explicitly stating that we now require MIT Kerberos when building with GSSAPI support. Reveiwed by: Johnathan Katz Discussion: https://postgr.es/m/abcc73d0-acf7-6896-e0dc-f5bc12a61bb1@postgresql.org
* De-Revert "Add support for Kerberos credential delegation"Stephen Frost2023-04-1336-136/+755
| | | | | | | | | | | | | | | | | | This reverts commit 3d03b24c3 (Revert Add support for Kerberos credential delegation) which was committed on the grounds of concern about portability, but on further review and discussion, it's clear that we are better off explicitly requiring MIT Kerberos as that appears to be the only GSSAPI library currently that's under proper maintenance and ongoing development. The API used for storing credentials was added to MIT Kerberos over a decade ago while for the other libraries which appear to be mainly based on Heimdal, which exists explicitly to be a re-implementation of MIT Kerberos, the API never made it to a released version (even though it was added to the Heimdal git repo over 5 years ago..). This post-feature-freeze change was approved by the RMT. Discussion: https://postgr.es/m/ZDDO6jaESKaBgej0%40tamriel.snowman.net
* doc: Make HTML ids discoverablePeter Eisentraut2023-04-132-0/+138
| | | | | | | | | | | | | | | In the HTML output, this decorates section headers and variable list terms with a marker ("#") that is a link to the same section/term. That way, links inside a page can be discovered for easier sharing. The marker only appears when hovering. This now requires that all elements that are candidates for such a link have an id attribute. Otherwise, an error will be generated. All previously missing ids have been added prior to this patch. Author: Brar Piening <brar@gmx.de> Reviewed-by: Karl O. Pinc <kop@karlpinc.com> Discussion: https://www.postgresql.org/message-id/flat/CAB8KJ=jpuQU9QJe4+RgWENrK5g9jhoysMw2nvTN_esoOU0=a_w@mail.gmail.com
* Add missing XML ID attributePeter Eisentraut2023-04-131-1/+1
| | | | Discussion: https://www.postgresql.org/message-id/dc813a6f-60d9-991f-eecd-675a0921de11@gmx.de
* Skip the 004_io_direct.pl test if a pre-flight check fails.Thomas Munro2023-04-131-8/+27
| | | | | | | | | | | | | | | | | The test previously had a list of OSes that direct I/O was expected to work on. That worked well enough for the systems in our build farm, but didn't survive contact with the Debian build bots running on tmpfs via overlayfs. tmpfs does not support O_DIRECT, but we don't want to exclude Linux generally. The new approach is to try to create an empty file with O_DIRECT from Perl first. If that fails, we'll skip the test and report what the error was. Reported-by: Christoph Berg <myon@debian.org> Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/ZDYd4A78cT2ULxZZ%40msg.df7cb.de
* Remove overzealous assertion from PHJ.Thomas Munro2023-04-131-1/+0
| | | | | | | | | | | | | | We can't assert that we're the only process attached to a barrier after BarrierArriveAndDetachExceptLast(). Although that'll be true almost always, a late-starting parallel worker can attach very briefly (that is, immediately detach after checking the phase) right at that moment. BarrierArriveAndDetachExceptLast() already contains an assertion like that, but it holds a spinlock preventing the race. This thinko caused a one-off failure on build farm animal chimaera. Diagnosed-by: Melanie Plageman <melanieplageman@gmail.com> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3590249.1680971629@sss.pgh.pa.us
* Revert "Adjust contrib/sepgsql regression test expected outputs."Alvaro Herrera2023-04-122-2/+12
| | | | | | | This reverts commit 76c111a7f166; should have been included in 9ce04b50e120. Noted by Joe Conway
* Improve error messages introduced in be87200efd9 and 0fdab27ad68Andres Freund2023-04-124-5/+5
| | | | | | Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20230411.120301.93333867350615278.horikyota.ntt@gmail.com Discussion: https://postgr.es/m/20230412174244.6njadz4uoiez3l74@awork3.anarazel.de
* Revert "Catalog NOT NULL constraints" and falloutAlvaro Herrera2023-04-1242-2874/+625
| | | | | | | | | | | This reverts commit e056c557aef4 and minor later fixes thereof. There's a few problems in this new feature -- most notably regarding pg_upgrade behavior, but others as well. This new feature is not in any way critical on its own, so instead of scrambling to fix it we revert it and try again in early 17 with these issues in mind. Discussion: https://postgr.es/m/3801207.1681057430@sss.pgh.pa.us
* basebackup_to_shell: Check for a NULL return from OpenPipeStream.Robert Haas2023-04-121-0/+5
| | | | | | Per complaint from Peter Eisentraut. Discussion: http://postgr.es/m/4f1707cc-2432-da35-64a2-5c2a8d92a388@enterprisedb.com
* Document BaseBackupSync and BaseBackupWrite wait events.Robert Haas2023-04-121-0/+8
| | | | | | | | | Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc should have done this, but I overlooked it. Per complaint from Thomas Munro. Discussion: http://postgr.es/m/CA+hUKGJixAHc860Ej9Qzd_z96Z6aoajAgJ18bYfV3Lfn6t9=+Q@mail.gmail.com
* Fix parallel-safety marking when moving initplans to another node.Tom Lane2023-04-124-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our policy since commit ab77a5a45 has been that a plan node having any initplans is automatically not parallel-safe. (This could be relaxed, but not today.) clean_up_removed_plan_level neglected this, and could attach initplans to a parallel-safe child plan node without clearing the plan's parallel-safe flag. That could lead to "subplan was not initialized" errors at runtime, in case an initplan referenced another one and only the referencing one got transmitted to parallel workers. The fix in clean_up_removed_plan_level is trivial enough. materialize_finished_plan also moves initplans from one node to another, but it's okay because it already copies the source node's parallel_safe flag. The other place that does this kind of thing is standard_planner's hack to inject a top-level Gather when debug_parallel_query is active. But that's actually dead code given that we're correctly enforcing the "initplans aren't parallel safe" rule, so just replace it with an Assert that there are no initplans. Also improve some related comments. Normally we'd add a regression test case for this sort of bug. The mistake itself is already reached by existing tests, but there is accidentally no visible problem. The only known test case that creates an actual failure seems too indirect and fragile to justify keeping it as a regression test (not least because it fails to fail in v11, though the bug is clearly present there too). Per report from Justin Pryzby. Back-patch to all supported branches. Discussion: https://postgr.es/m/ZDVt6MaNWkRDO1LQ@telsasoft.com
* doc: Reword unexplained abbreviationDaniel Gustafsson2023-04-122-1/+21
| | | | | | | | | | | | | The previous wording used MVF to indicate the Most Common Values' Frequencies, but the abbreviation was never explained or defined. Reword to mcv_freqs to make the use clearer. Also add MCF and MCV as acronyms as they were using <acronym> markup but were missing from the acronyms page. Reported-by: Eric Mutta <eric.mutta@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/166112292492.654.5377188452604176150@wrigleys.postgresql.org
* Fix incorrect format placeholdersPeter Eisentraut2023-04-123-4/+4
|
* Update config.guess and config.subPeter Eisentraut2023-04-122-22/+59
|
* doc: Fix some typos and grammarMichael Paquier2023-04-1212-22/+21
| | | | | | | | This is a first batch of the fixes, for the most obvious fixes. A little bit more is under discussion. Author: Thom Brown, Justin Pryzby Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
* Fix detection of unseekable files for fseek() and ftello() with MSVCMichael Paquier2023-04-128-22/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling fseek() or ftello() on a handle to a non-seeking device such as a pipe or a communications device is not supported. Unfortunately, MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not return an error when given a pipe as handle. Some of the logic of pg_dump and restore relies on these routines to check if a handle is seekable, causing failures when passing the contents of pg_dump to pg_restore through a pipe, for example. This commit introduces wrappers for fseeko() and ftello() on MSVC so as any callers are able to properly detect the cases of non-seekable handles. This relies mainly on GetFileType(), sharing a bit of code with the MSVC port for fstat(). The code in charge of getting a file type is refactored into a new file called win32common.c, shared by win32stat.c and the new win32fseek.c. It includes the MSVC ports for fseeko() and ftello(). Like 765f5df, this is backpatched down to 14, where the fstat() implementation for MSVC is able to understand about files larger than 4GB in size. Using a TAP test for that is proving to be tricky as IPC::Run handles the pipes by itself, still I have been able to check the fix manually. Reported-by: Daniel Watzinger Author: Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com Backpatch-through: 14
* Refine the guidelines for rmgrdesc authors.Peter Geoghegan2023-04-112-20/+44
| | | | | | | | | | | | | | | | Clarify the goals of the recently added guidelines for rmgrdesc authors: to avoid gratuitous inconsistencies across resource managers, and to make it reasonably easy to write a reusable custom parser. Beyond that, the guidelines leave rmgrdesc authors with a significant amount of leeway. This even includes the leeway to invent custom conventions (in cases where it's warranted). Follow-up to commit 7d8219a4. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/CAH2-WzkbYuvwYKm-Y-72QEh6SPMQcAo9uONv+mR3bMGcu9E_Cg@mail.gmail.com
* Fix Heap rmgr's desc output for infobits arrays.Peter Geoghegan2023-04-111-49/+71
| | | | | | | | | | | | | | | | | | | Make heap desc routines that output status bit as arrays of constants avoid outputting array literals that contain superfluous punctuation characters that complicate parsing the output. Also make sure that no heap desc routine repeats the same key name (at the same nesting level), for the same reason. Arguably, these were both oversights in commit 7d8219a4. In passing, make the desc output code (which covers Heap's DELETE, UPDATE, HOT_UPDATE, LOCK, and LOCK_UPDATED record types) consistent in terms of the output order of each field. This order also matches WAL record struct order. Heap's DELETE desc output now shows the record's xmax field for the first time (just like UPDATE/HOT_UPDATE records). Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/CAH2-Wz=pNYtxiJ2Jx5Lj=fKo1OEZ4GE0p_kct+ugAUTqBwU46g@mail.gmail.com
* Fix xl_heap_lock WAL record field's data type.Peter Geoghegan2023-04-113-8/+8
| | | | | | | | | | | | | | Make xl_heap_lock's infobits_set field of type uint8, not int8. Using int8 isn't appropriate given that the field just holds status bits. This fixes an oversight in commit 0ac5ad5134. In passing rename the nearby TransactionId field to "xmax" to make things consistency with related records, such as xl_heap_lock_updated. Deliberately avoid a bump in XLOG_PAGE_MAGIC. No backpatch, either. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkCd3kOS8b7Rfxw7Mh1_6jvX=Nzo-CWR1VBTiOtVZkWHA@mail.gmail.com
* 035_standby_logical_decoding: Add missing waits for replicationAndres Freund2023-04-111-0/+6
| | | | | | | | | | At least one slow buildfarm system (hoverfly) showed that the database creation was not replicated before we try to create logical replication slots on the standby, in that database. Reported-by: Noah Misch <noah@leadboat.com> Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/20230411053657.GA1177147@rfd.leadboat.com
* Document new pg_subscription columns.Robert Haas2023-04-111-0/+20
| | | | | | | | | | Commit 482675987bcdffb390ae735cfd5f34b485ae97c6 and commit c3afe8cf5a1e465bd71e48e4bc717f5bfdc7a7d6 forgot to take care of this. Noriyoshi Shinoda Discussion: http://postgr.es/m/DM4PR84MB17345D8760165F14A199B81CEE9A9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
* Fix uninitialized variable in transformTableLikeClause()David Rowley2023-04-111-1/+1
| | | | | | | | | process_notnull_constraints should be set to false until we discover a NOT NULL column. Discovered while running Valgrind. Discussion: https://postgr.es/m/CAApHDvoMyiZVi1KW5WVdqMRzWsWkD3F7n6QD+BbAO6WTeAWsUQ@mail.gmail.com
* Improve ereports for VACUUM's BUFFER_USAGE_LIMIT optionDavid Rowley2023-04-112-28/+11
| | | | | | | | | | | | | | There's no need to check if opt->arg is NULL since defGetString() already does that and raises an ERROR if it is. Let's just remove that check. Also, combine the two remaining ERRORs into a single check. It seems better to give an indication about what sort of values we're looking for rather than just to state that the value given isn't valid. Make BUFFER_USAGE_LIMIT uppercase in this ERROR message too. It's already upper case in one other error message, so make that consistent. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230411.102335.1643720544536884844.horikyota.ntt@gmail.com
* Doc: use "an SQL" consistently rather than "a SQL"David Rowley2023-04-111-3/+3
| | | | | | | | | | | Similarly to what was done in 04539e73f and 7bdd489d3, we standardized on SQL being pronounced "es-que-ell" rather than "sequel" in our documentation. This fixes the instances of "a SQL" that have crept in during the v16 cycle. Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com
* Clarify nbtree posting list update desc issue.Peter Geoghegan2023-04-101-0/+5
| | | | | | | | | Per complaint from Melanie Plageman. Follow-up to commit 5d6728e5. Reported-By: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20230411002315.oyaicmcqrq2hb3ek@liskov
* Doc: add missed entries in BRIN extensibility tables.Tom Lane2023-04-101-0/+8
| | | | | | | | | The tables in "71.3. Extensibility" listing the support functions for bloom and minmax-multi opclasses should include the associated options function. While this isn't quite as required as the rest, you need it for full functionality of the opclass. Back-patch to v14 where these functions were added.
* Fix nbtree posting list update desc output.Peter Geoghegan2023-04-105-98/+87
| | | | | | | | | | | | | | | | | | | | | | | | | We cannot use the generic array_desc approach with per-tuple nbtree posting list update metadata because array_desc can only deal with fixed width elements (e.g., page offset numbers). Using array_desc led to incorrect rmgr descriptions for updates from nbtree DELETE/VACUUM WAL records. To fix, add specialized code to describe the update metadata as array elements in desc output. We now iterate over the update metadata using an approach that matches related REDO routines. Also stop showing the updates offset number array separately in nbtree DELETE/VACUUM desc output. It's redundant information, since the same page offset numbers appear in the description of each individual update element. Also make some small tweaks to the way that we format arrays in all desc routines (not just nbtree desc routines) to make arrays a little less verbose. Oversight in commit 1c453cfd, which enhanced the nbtree rmgr desc routines. Author: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/CAH2-WzkbYuvwYKm-Y-72QEh6SPMQcAo9uONv+mR3bMGcu9E_Cg@mail.gmail.com
* Doc: adjust examples of EXTRACT() output to match current reality.Tom Lane2023-04-101-8/+8
| | | | | | | | | | | | | | | | | | | | | EXTRACT(EPOCH), EXTRACT(SECOND), and some related cases print more trailing zeroes than they used to. This behavior change happened with commit a2da77cdb (Change return type of EXTRACT to numeric), and it was intentional according to the commit log: - Return values when extracting fields with possibly fractional values, such as second and epoch, now have the full scale that the value has internally (so, for example, '1.000000' instead of just '1'). It's been like that for two releases now, so while I suggested changing this back, it's probably better to adjust the documentation examples. Per bug #17866 from Евгений Жужнев. Back-patch to v14 where the change came in. Discussion: https://postgr.es/m/17866-18eb70095b1594e2@postgresql.org
* Doc: avoid using pg_get_publication_tables() in an example.Tom Lane2023-04-101-6/+8
| | | | | | | | | | | pg_get_publication_tables() is undocumented because it's only meant as infrastructure for the pg_publication_tables system view. That being the case, we should use the view not the bare function in this sample query. Shi Yu Discussion: https://postgr.es/m/OSZPR01MB63107E83D07FEDEEABD83A23FD949@OSZPR01MB6310.jpnprd01.prod.outlook.com
* Simplify version check for SKIP clauseDaniel Gustafsson2023-04-081-1/+1
| | | | | | | | | | Checking for the required versions of IO::Pty as well as IPC::Run can be achieved with a single eval call, and by using the VERSION function the comparison is guaranteed to follow the same rules as calling 'use' on the module with a version. Reported-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/6d880ea2-f8ca-f458-4dcd-a7a3e6d6cd7c@dunslane.net
* Use higher wal_level for 004_io_direct.pl.Thomas Munro2023-04-091-0/+1
| | | | | | | | | | | | | | | The new direct I/O test deliberately uses a very small shared_buffers to force some disk transfers without making the data set large and slow, but ran into a problem with wal_level = minimal: log_newpage_range() pins many buffers, leading to a few intermittent "no unpinned buffers available" errors. We could presumably fix that by adjusting shared_buffers, but crake seems to be trying to tell us something interesting with these settings, so let's just avoid wal_level = minimal in this test for now. Reported-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20230408060408.n7xdwk3mxj5oykt6%40awork3.anarazel.de
* Improve indentation of multiline initialization expressions.Tom Lane2023-04-083-7/+8
| | | | | | | | | | | | | If a variable has an initialization expression that wraps onto the next line(s), pg_bsd_indent will now indent the continuation lines one stop, instead of aligning them flush with the variable declaration. We've been holding off applying this until the last v16 CF finished, but now it's time. Thomas Munro and Tom Lane Discussion: https://postgr.es/m/20230120013137.7ky7nl4e4zjorrfa@awork3.anarazel.de
* Try to unbreak MSVC builds for pg_waldumpAndrew Dunstan2023-04-081-1/+1
| | | | remedy an omission in commit 7d8219a444
* Suppress bogus printout during new 035_standby_logical_decoding.pl test.Tom Lane2023-04-081-1/+1
| | | | | | Our convention for some time has been that successful tests shouldn't print anything on stderr. A stray "diag" call violated that, and for that matter messed up the normal TAP progress display.
* Skip \password TAP test on old IPC::Run versionsDaniel Gustafsson2023-04-081-2/+4
| | | | | | | | | IPC::Run versions prior to 0.98 cause the interactive session to time out, so SKIP the test in case these versions are detected (they are within the base requirement for our TAP tests in general). Error reported by the BF and investigation by Tom Lane. Discussion: https://postgr.es/m/414A86BD-986B-48A7-A1E4-EEBCE5AF08CB@yesql.se
* Try to unbreak MSVC builds for fuzzystrmatchAndrew Dunstan2023-04-081-0/+10
| | | | | | | Commit a290378a37 neglrected to add a recipe for MSVC to build the daitch_motokoff.h file. Per buildfarm animal bowerbird.
* Revert "Add support for Kerberos credential delegation"Stephen Frost2023-04-0836-755/+136
| | | | | | | | | | | This reverts commit 3d4fa227bce4294ce1cc214b4a9d3b7caa3f0454. Per discussion and buildfarm, this depends on APIs that seem to not be available on at least one platform (NetBSD). Should be certainly possible to rework to be optional on that platform if necessary but bit late for that at this point. Discussion: https://postgr.es/m/3286097.1680922218@sss.pgh.pa.us
* Redesign interrupt/cancel API for regex engine.Thomas Munro2023-04-0813-104/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, a PostgreSQL-specific callback checked by the regex engine had a way to trigger a special error code REG_CANCEL if it detected that the next call to CHECK_FOR_INTERRUPTS() would certainly throw via ereport(). A later proposed bugfix aims to move some complex logic out of signal handlers, so that it won't run until the next CHECK_FOR_INTERRUPTS(), which makes the above design impossible unless we split CHECK_FOR_INTERRUPTS() into two phases, one to run logic and another to ereport(). We may develop such a system in the future, but for the regex code it is no longer necessary. An earlier commit moved regex memory management over to our MemoryContext system. Given that the purpose of the two-phase interrupt checking was to free memory before throwing, something we don't need to worry about anymore, it seems simpler to inject CHECK_FOR_INTERRUPTS() directly into cancelation points, and just let it throw. Since the plan is to keep PostgreSQL-specific concerns separate from the main regex engine code (with a view to bein able to stay in sync with other projects), do this with a new macro INTERRUPT(), customizable in regcustom.h and defaulting to nothing. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com
* Update contrib/trgm_regexp's memory management.Thomas Munro2023-04-081-15/+2
| | | | | | | | | While no code change was necessary for this code to keep working, we don't need to use PG_TRY()/PG_FINALLY() with explicit clean-up while working with regexes anymore. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com
* Update tsearch regex memory management.Thomas Munro2023-04-082-39/+13
| | | | | | | | | | Now that our regex engine uses palloc(), it's not necessary to set up a special memory context callback to free compiled regexes. The regex has no resources other than the memory that is already going to be freed in bulk. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com
* Use MemoryContext API for regex memory management.Thomas Munro2023-04-083-20/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, regex_t objects' memory was managed with malloc() and free() directly. Switch to palloc()-based memory management instead. Advantages: * memory used by cached regexes is now visible with MemoryContext observability tools * cleanup can be done automatically in certain failure modes (something that later commits will take advantage of) * cleanup can be done in bulk On the downside, there may be more fragmentation (wasted memory) due to per-regex MemoryContext objects. This is a problem shared with other cached objects in PostgreSQL and can probably be improved with later tuning. Thanks to Noah Misch for suggesting this general approach, which unblocks later work on interrupts. Suggested-by: Noah Misch <noah@leadboat.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGK3PGKwcKqzoosamn36YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com
* TAP test for logical decoding on standbyAndres Freund2023-04-083-0/+772
| | | | | | | | | | | | Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Author: Amit Khandekar <amitdkhan.pg@gmail.com> Author: Craig Ringer <craig@2ndquadrant.com> (in an older version) Author: Andres Freund <andres@anarazel.de> Reviewed-by: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Fabrízio de Royes Mello <fabriziomello@gmail.com>
View Lorry Controller Status