aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Remove duplicate initializationAlvaro Herrera2022-09-14
| | | | | | | | | | | | This appears to be a merge mistake in 96ef3237bf74. We could put it back the way it was before JSON_TABLE and it'd be two lines shorter, but it's likely that JSON_TABLE will be back and will prefer things this way. It makes no other difference in practice. Backpatch to 15. Reported by Ranier Vilela Discussion: https://postgr.es/m/CAEudQAr4nOcNQskC4oBEZN4S+4heJ=1ch_ZKOxU+_Ef-FQSf-g@mail.gmail.com
* postgres_fdw: Avoid 'variable not found in subplan target list' error.Etsuro Fujita2022-09-14
| | | | | | | | | | | | | | | | | | | | | | The tlist of the EvalPlanQual outer plan for a ForeignScan node is adjusted to produce a tuple whose descriptor matches the scan tuple slot for the ForeignScan node. But in the case where the outer plan contains an extra Sort node, if the new tlist contained columns required only for evaluating PlaceHolderVars or columns required only for evaluating local conditions, this would cause setrefs.c to fail with the error. The cause of this is that when creating the outer plan by injecting the Sort node into an alternative local join plan that could emit such extra columns as well, we fail to arrange for the outer plan to propagate them up through the Sort node, causing setrefs.c to fail to match up them in the new tlist to what is available from the outer plan. Repair. Per report from Alexander Pyhalov. Richard Guo and Etsuro Fujita, reviewed by Alexander Pyhalov and Tom Lane. Backpatch to all supported versions. Discussion: http://postgr.es/m/cfb17bf6dfdf876467bd5ef533852d18%40postgrespro.ru
* Fix failure to build gramparse.h standalone in vpath buildsJohn Naylor2022-09-14
| | | | | | Add include directory in a similar fashion as 829906fb6c. Per buildfarm animal crake
* Fix incorrect value for "strategy" with deflateParams() in walmethods.cMichael Paquier2022-09-14
| | | | | | | | | | | | | | The zlib documentation mentions the values supported for the compression strategy, but this code has been using a hardcoded value of 0 rather than Z_DEFAULT_STRATEGY. This commit adjusts the code to use Z_DEFAULT_STRATEGY. Backpatch down to where this code has been added to ease the backport of any future patch touching this area. Reported-by: Tom Lane Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us Backpatch-through: 10
* Fix typo in pgbench.c.Amit Kapila2022-09-14
| | | | | Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20220914.114608.1462991533784489178.horikyota.ntt@gmail.com
* Bump minimum Perl version to 5.14John Naylor2022-09-14
| | | | | | | | | | | | | | | | | | | | The oldest vendor-shipped Perl in the buildfarm is 5.14.2, which is the last version that Debian Wheezy shipped. That OS is EOL, but we keep it running because there is no other convenient way to test certain non-mainstream 32-bit platforms. There is no bugfix in the 5.14.2 release that is required, and yet it's also not the latest minor release -- that would be 5.14.4. To clarify the situation, we have thus arranged the buildfarm to test 5.14.0. That allows configure scripts and documentation to state 5.14 without fine print. The MSVC build didn't check the version, since our previous minimum 5.8.3 was considered too old to check for on Windows. We will need a check for Windows sometime during the v16 cycle, but that could be rendered moot by the impending Meson conversion, so it seems safe to just document the requirement for now. Reviewed by Tom Lane Discussion: https://www.postgresql.org/message-id/20220902181553.ev4pgzhubhdkguuv@awork3.anarazel.de
* Move gramparse.h to src/backend/parserJohn Naylor2022-09-14
| | | | | | | | | | | | | This header is semi-private, being used only in files related to raw parsing, so move to the backend directory where those files live. This allows removal of Makefile rules that symlink gram.h to src/include/parser, since gramparse.h can now include gram.h from within the same directory. This has the side-effect of no longer installing gram.h and gramparse.h, but there doesn't seem to be a good reason to continue doing so. Per suggestion from Andres Freund and Peter Eisentraut Discussion: https://www.postgresql.org/message-id/20220904181759.px6uosll6zbxcum5%40awork3.anarazel.de
* Simplify handling of compression level with compression specificationsMichael Paquier2022-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PG_COMPRESSION_OPTION_LEVEL is removed from the compression specification logic, and instead the compression level is always assigned with each library's default if nothing is directly given. This centralizes the checks on the compression methods supported by a given build, and always assigns a default compression level when parsing a compression specification. This results in complaining at an earlier stage than previously if a build supports a compression method or not, aka when parsing a specification in the backend or the frontend, and not when processing it. zstd, lz4 and zlib are able to handle in their respective routines setting up the compression level the case of a default value, hence the backend or frontend code (pg_receivewal or pg_basebackup) has now no need to know what the default compression level should be if nothing is specified: the logic is now done so as the specification parsing assigns it. It can also be enforced by passing down a "level" set to the default value, that the backend will accept (the replication protocol is for example able to handle a command like BASE_BACKUP (COMPRESSION_DETAIL 'gzip:level=-1')). This code simplification fixes an issue with pg_basebackup --gzip introduced by ffd5365, where the tarball of the streamed WAL segments would be created as of pg_wal.tar.gz with uncompressed contents, while the intention is to compress the segments with gzip at a default level. The origin of the confusion comes from the handling of the default compression level of gzip (-1 or Z_DEFAULT_COMPRESSION) and the value of 0 was getting assigned, which is what walmethods.c would consider as equivalent to no compression when streaming WAL segments with its tar methods. Assigning always the compression level removes the confusion of some code paths considering a value of 0 set in a specification as either no compression or a default compression level. Note that 010_pg_basebackup.pl has to be adjusted to skip a few tests where the shape of the compression detail string for client and server-side compression was checked using gzip. This is a result of the code simplification, as gzip specifications cannot be used if a build does not support it. Reported-by: Tom Lane Reviewed-by: Tom Lane Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us Backpatch-through: 15
* Split up guc.c for better build speed and ease of maintenance.Tom Lane2022-09-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | guc.c has grown to be one of our largest .c files, making it a bottleneck for compilation. It's also acquired a bunch of knowledge that'd be better kept elsewhere, because of our not very good habit of putting variable-specific check hooks here. Hence, split it up along these lines: * guc.c itself retains just the core GUC housekeeping mechanisms. * New file guc_funcs.c contains the SET/SHOW interfaces and some SQL-accessible functions for GUC manipulation. * New file guc_tables.c contains the data arrays that define the built-in GUC variables, along with some already-exported constant tables. * GUC check/assign/show hook functions are moved to the variable's home module, whenever that's clearly identifiable. A few hard- to-classify hooks ended up in commands/variable.c, which was already a home for miscellaneous GUC hook functions. To avoid cluttering a lot more header files with #include "guc.h", I also invented a new header file utils/guc_hooks.h and put all the GUC hook functions' declarations there, regardless of their originating module. That allowed removal of #include "guc.h" from some existing headers. The fallout from that (hopefully all caught here) demonstrates clearly why such inclusions are best minimized: there are a lot of files that, for example, were getting array.h at two or more levels of remove, despite not having any connection at all to GUCs in themselves. There is some very minor code beautification here, such as renaming a couple of inconsistently-named hook functions and improving some comments. But mostly this just moves code from point A to point B and deals with the ensuing needs for #include adjustments and exporting a few functions that previously weren't exported. Patch by me, per a suggestion from Andres Freund; thanks also to Michael Paquier for the idea to invent guc_funcs.c. Discussion: https://postgr.es/m/587607.1662836699@sss.pgh.pa.us
* Don't reflect unescaped cert data to the logsPeter Eisentraut2022-09-13
| | | | | | | | | | | | | | | | | | | | | | Commit 3a0e385048 introduced a new path for unauthenticated bytes from the client certificate to be printed unescaped to the logs. There are a handful of these already, but it doesn't make sense to keep making the problem worse. \x-escape any unprintable bytes. The test case introduces a revoked UTF-8 certificate. This requires the addition of the `-utf8` flag to `openssl req`. Since the existing certificates all use an ASCII subset, this won't modify the existing certificates' subjects if/when they get regenerated; this was verified experimentally with $ make sslfiles-clean $ make sslfiles Unfortunately the test can't be run in the CI yet due to a test timing issue; see 55828a6b60. Author: Jacob Champion <jchampion@timescale.com> Discussion: https://www.postgresql.org/message-id/CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com
* pg_clean_ascii(): escape bytes rather than lose themPeter Eisentraut2022-09-13
| | | | | | | | | Rather than replace each unprintable byte with a '?' character, replace it with a hex escape instead. The API now allocates a copy rather than modifying the input in place. Author: Jacob Champion <jchampion@timescale.com> Discussion: https://www.postgresql.org/message-id/CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com
* Make locale option behavior more consistentPeter Eisentraut2022-09-13
| | | | | | | | | | | | | | | | | | | Locale options can be specified for initdb, createdb, and CREATE DATABASE. In initdb, it has always been possible to specify --locale and then some --lc-* option to override a category. CREATE DATABASE and createdb didn't allow that, requiring either the all-categories option or only per-category options. In f2553d43060edb210b36c63187d52a632448e1d2, this was changed in CREATE DATABASE (perhaps by accident?) to be more like the initdb behavior, but createdb still had the old behavior. Now we change createdb to match the behavior of CREATE DATABASE and initdb, and also update the documentation of CREATE DATABASE to match the new behavior, which was not done in the above commit. Author: Marina Polyakova <m.polyakova@postgrespro.ru> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://www.postgresql.org/message-id/7c99c132dc9c0ac630e0127f032ac480@postgrespro.ru
* Improve wal_decode_buffer_size description some moreAlvaro Herrera2022-09-13
| | | | | | Per Thomas Munro Discussion: https://postgr.es/m/CA+hUKGJ9wP9kpvgoxHvqA=4g1d9-y_w3LhhdhFVU=mFiqjwHww@mail.gmail.com
* Remove useless pstrdups in untransformRelOptionsAlvaro Herrera2022-09-13
| | | | | | | | | | | | | | | The two strings are already a single palloc'd chunk, not freed; there's no reason to allocate separate copies that have the same lifetime. This code is only called in short-lived memory contexts (except in some cases in TopTransactionContext, which is still short-lived enough not to really matter), and typically only for short arrays, so the memory or computation saved is likely negligible. However, let's fix it to avoid leaving a bad example of code to copy. This is the only place I could find where we're doing this with makeDefElem(). Reported-by: Junwang Zhao <zhjwpku@gmail.com> Discussion: https://postgr.es/m/20220909142050.3vv2hjekppk265dd@alvherre.pgsql
* Adjust header exceptions for 0bd9c6297John Naylor2022-09-13
| | | | Per buildfarm animal crake
* Treat Unicode codepoints of category "Format" as non-spacingJohn Naylor2022-09-13
| | | | | | | | | | | | | | | | | | | | Commit d8594d123 updated the list of non-spacing codepoints used for calculating display width, but in doing so inadvertently removed some, since the script used for that commit only considered combining characters. For complete coverage for zero-width characters, include codepoints in the category Cf (Format). To reflect the wider purpose, also rename files and update comments that referred specifically to combining characters. Some of these ranges have been missing since v12, but due to lack of field complaints it was determined not important enough to justify adding special-case logic the backbranches. Kyotaro Horiguchi Report by Pavel Stehule Discussion: https://www.postgresql.org/message-id/flat/CAFj8pRBE8yvpQ0FSkPCoe0Ny1jAAsAQ6j3qMgVwWvkqAoaaNmQ%40mail.gmail.com
* Rename macro related to pg_backup_stop()Michael Paquier2022-09-13
| | | | | | | | | This should have been part of 39969e2 that has renamed pg_stop_backup() to pg_backup_stop(), and this one is the last reference to pg_stop/start_backup() I could find in the tree. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACXjvC28ppeDTCrfaSyHga0ggP5nRLJbsjx=7N-74UT4QA@mail.gmail.com
* Move any remaining files generated by pg_upgrade into an internal subdirMichael Paquier2022-09-13
| | | | | | | | | | | | | | | | | This change concerns a couple of .txt files (for internal state checks) that were still written in the path where the binary is executed, and not in the subdirectory located in the target cluster. Like the other .txt files doing already so (like loadable_libraries.txt), these are saved in the base output directory. Note that on failure, the logs report the full path to the .txt file generated, so these are easy to find. Oversight in 38bfae3. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Justin Prysby Discussion: https://postgr.es/m/181A6DA8-3B7F-4B71-82D5-363FF0146820@yesql.se Backpatch-through: 15
* Don't reference out-of-bounds array elements in brin_minmax_multi.cDavid Rowley2022-09-13
| | | | | | | | | | | | | | | | | | The primary fix here is to fix has_matching_range() so it does not reference ranges->values[-1] when nranges == 0. Similar problems existed in AssertCheckRanges() too. It does not look like any of these problems could lead to a crash as the array in question is at the end of the Ranges struct, and values[-1] is memory that belongs to other fields in the struct. However, let's get rid of these rather unsafe coding practices. In passing, I (David) adjusted some comments to try to make it more clear what some of the fields are for in the Ranges struct. I had to study the code to find out what nsorted was for as I couldn't tell from the comments. Author: Ranier Vilela Discussion: https://postgr.es/m/CAEudQAqJQzPitufX-jR=YUbJafpCDAKUnwgdbX_MzSc93wuvdw@mail.gmail.com Backpatch-through: 14, where multi-range brin was added.
* doc: Fix link to FreeBSD documentation projectDaniel Gustafsson2022-09-12
| | | | | | | | The FreeBSD site was changed with a redirect, which in turn seems to lead to a 404. Replace with the working link. Author: James Coleman <jtc331@gmail.com> Discussion: https://postgr.es/m/CAAaqYe_JZRj+KPn=hACtwsg1iLRYs=jYvxG1NW4AnDeUL1GD-Q@mail.gmail.com
* Use normal install program to install server headers.Heikki Linnakangas2022-09-12
| | | | | | | | | | | | | Commit a7032690f9 replaced $(INSTALL) with plain "cp" for installing the server header files. It sped up "make install" significantly, because the old logic called $(INSTALL) separately for every header file, whereas plain "cp" could copy all the files in one command. However, we have long since made it a requirement that $(INSTALL) can also install multiple files in one command, see commit f1c5247563. Switch back to $(INSTALL). Discussion: https://www.postgresql.org/message-id/200503252305.j2PN52m23610%40candle.pha.pa.us Discussion: https://www.postgresql.org/message-id/2415283.1641852217%40sss.pgh.pa.us
* Revert "Convert *GetDatum() and DatumGet*() macros to inline functions"Peter Eisentraut2022-09-12
| | | | | | This reverts commit 595836e99bf1ee6d43405b885fb69bb8c6d3ee23. It has problems when USE_FLOAT8_BYVAL is off.
* Convert *GetDatum() and DatumGet*() macros to inline functionsPeter Eisentraut2022-09-12
| | | | | | | | | The previous macro implementations just cast the argument to a target type but did not check whether the input type was appropriate. The function implementation can do better type checking of the input type. Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://www.postgresql.org/message-id/flat/8528fb7e-0aa2-6b54-85fb-0c0886dbd6ed%40enterprisedb.com
* Fix NaN comparison in circle_same testDaniel Gustafsson2022-09-12
| | | | | | | | | | | | | | | | | | | | | | Commit c4c340088 changed geometric operators to use float4 and float8 functions, and handle NaN's in a better way. The circle sameness test had a typo in the code which resulted in all comparisons with the left circle having a NaN radius considered same. postgres=# select '<(0,0),NaN>'::circle ~= '<(0,0),1>'::circle; ?column? ---------- t (1 row) This fixes the sameness test to consider the radius of both the left and right circle. Backpatch to v12 where this was introduced. Author: Ranier Vilela <ranier.vf@gmail.com> Discussion: https://postgr.es/m/CAEudQAo8dK=yctg2ZzjJuzV4zgOPBxRU5+Kb+yatFiddtQk6Rw@mail.gmail.com Backpatch-through: v12
* pgstattuple: Use double consistently for percentagesPeter Eisentraut2022-09-12
| | | | | | | | | | | | pgstattuple uses data type double for other percentage calculations and exposes those values to the users via the float8 data type. However, scanned_percent in struct output_type is of type uint64, even though it is later returned via Float8GetDatum(). Change it to use double to be inline with other percentages. Author: Bharath Rupireddy Reviewed-by: Peter Eisentraut Discussion: https://www.postgresql.org/message-id/36ee692b-232f-0484-ce94-dc39d82021ad%40enterprisedb.com
* Use float8 datatype for percentiles in pg_walinspect stat functionsPeter Eisentraut2022-09-12
| | | | | | | | | | | | | | | pg_walinspect uses datatype double (double precision floating point number) for WAL stats percentile calculations and expose them via float4 (single precision floating point number), which an unnecessary loss of precision and confusing. Even though, it's harmless that way, let's use float8 (double precision floating-point number) to be in sync with what pg_walinspect does internally and what it exposes to the users. This seems to be the pattern used elsewhere in the code. Reported-by: Peter Eisentraut Author: Bharath Rupireddy Reviewed-by: Peter Eisentraut Discussion: https://www.postgresql.org/message-id/36ee692b-232f-0484-ce94-dc39d82021ad%40enterprisedb.com
* Make the tablesync worker's replication origin drop logic robust.Amit Kapila2022-09-12
| | | | | | | | | | | | | | | | | | | | | | | In commit f6c5edb8ab, we started to drop the replication origin slots before tablesync worker exits to avoid consuming more slots than required. We were dropping the replication origin in the same transaction where we were marking the tablesync state as SYNCDONE. Now, if there is any error after we have dropped the origin but before we commit the containing transaction, the in-memory state of replication progress won't be rolled back. Due to this, after the restart, tablesync worker can start streaming from the wrong location and can apply the already processed transaction. To fix this, we need to opportunistically drop the origin after marking the tablesync state as SYNCDONE. Even, if the tablesync worker fails to remove the replication origin before exit, the apply worker ensures to clean it up afterward. Reported by Tom Lane as per buildfarm. Diagnosed-by: Masahiko Sawada Author: Hou Zhijie Reviewed-By: Masahiko Sawada, Amit Kapila Discussion: https://postgr.es/m/20220714115155.GA5439@depesz.com Discussion: https://postgr.es/m/CAD21AoAw0Oofi4kiDpJBOwpYyBBBkJj=sLUOn4Gd2GjUAKG-fw@mail.gmail.com
* Assorted examples of expanded type-safer palloc/pg_malloc APIPeter Eisentraut2022-09-12
| | | | | | | | | This adds some uses of the new palloc/pg_malloc variants here and there as a demonstration and test. This is kept separate from the actual API patch, since the latter might be backpatched at some point. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
* Expand palloc/pg_malloc API for more type safetyPeter Eisentraut2022-09-12
| | | | | | | | | | | | | | | | | This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
* Make eval statement naturally proof against perltidyJohn Naylor2022-09-12
| | | | | | | | | This is a bit less verbose than adding an exception. Rewrite the other eval statement in Catalog.pm as well, just for the sake of consistency. Idea from Andrew Dunstan Discussion: https://www.postgresql.org/message-id/CAD5tBc%2BzRhuWn_S4ayH2sWKe60FQu1guTTokDFS3YMOeSrsozA%40mail.gmail.com
* Replace loading of ldap_start_tls_sA() by direct function callMichael Paquier2022-09-12
| | | | | | | | | | | | | | | This change impacts the backend-side code in charge of starting a LDAP TLS session. It is a bit sad that it is not possible to unify the WIN32 and non-WIN32 code paths, but the different number of arguments for both discard this possibility. This is similar to 47bd0b3, where this replaces the last function loading that seems worth it, any others being either environment or version-dependent. Reported-by: Thomas Munro Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/Yx0rxpNgDh8tN4XA@paquier.xyz
* Doc: improve explanation of when custom GUCs appear in pg_settings.Tom Lane2022-09-10
| | | | | | | | | | | | | | Be more clear about when and how an extension-defined GUC comes to be visible in pg_settings. (Move the para to the bottom of the page, too; whoever thought this point was more important than the para about the view being updatable had odd priorities IMNSHO.) Back-patch to v15 where archive modules were added, since that seems to have made this more of a sore spot than it was before. Benoit Lobréau, Nathan Bossart Discussion: https://postgr.es/m/CAPE8EZ7KHaXMHKwT=HOim23tDVKYA1PruRuTfeYdCrYWwPGhag@mail.gmail.com
* Add psql tab compression for ALTER TABLE .. { OF | NOT OF }Michael Paquier2022-09-10
| | | | | | | | | ALTER TABLE .. OF is now able to complete with the list of available composite types that can be used with the query. Author: Aleksander Alekseev Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/47b71e0c523b30357208e79786161281@oss.nttdata.com
* Free correctly LDAPMessage returned by ldap_search_s() in auth.cMichael Paquier2022-09-10
| | | | | | | | | | | | | | | | The LDAP wiki states that the search message should be freed regardless of the return value of ldap_search_s(), but we failed to do so in one backend code path when searching LDAP with a filter. This is not critical in an authentication code path failing in the backend as this causes such the process to exit promptly, but let's be clean and free the search message appropriately, as documented by upstream. All the other code paths failing a LDAP operation do that already, and somebody looking at this code in the future may miss what LDAP expects with the search message. Author: Zhihong Yu Discussion: https://postgr.es/m/CALNJ-vTf5Y+8RtzZ4GjOGE9qWVHZ8awfhnFYc_qGm8fMLUNRAg@mail.gmail.com
* configure: Expand -fvisibility checks to more compilers, test for -qvisibilityAndres Freund2022-09-09
| | | | | | | | | | | | | | | | It looks like icc and sunpro both support -fvisibility=hidden and xlc supports -qvisibility=hidden. I tested this on AIX and solaris with their proprietary compilers as well as gcc, and with gcc or clang on freebsd, linux, macos, netbsd and openbsd. Apparently my prior commit fe6a64a58ab only works in combination with this patch. While I tried to test them separately, an unknown caching issue prevented me from noticing the problem. Per discussion with Tom Lane and buildfarm member hoverfly. Discussion: https://postgr.es/m/20220910052741.t7w7csyrggwus2ze%40awork3.anarazel.de Discussion: https://postgr.es/m/20220820174213.d574qde4ptwdzoqz@awork3.anarazel.de
* aix: No need to use mkldexport when we want to export all symbolsAndres Freund2022-09-09
| | | | | | | | | | | | | | | | | When building a shared library with exports.txt there's no need to build an intermediary static library, we can just pass -Wl,-bE:... when generating the .so. When building a shared library without exports.txt, there's no need to call mkldexport.sh to export all symbols, because all symbols are exported anyway, and we don't need the export file on the import side (like we do for postgres.imp). This makes building .so's on aix a lot more similar to building on other platforms. In particular, we don't create and remove a .a of the same name but different contents anymore. Discussion: https://postgr.es/m/20220820174213.d574qde4ptwdzoqz@awork3.anarazel.de
* Fix possible omission of variable storage markers in ECPG.Tom Lane2022-09-09
| | | | | | | | | | | | | | | | | | | | | | | The ECPG preprocessor converted code such as static varchar str1[10], str2[20], str3[30]; into static struct varchar_1 { int len; char arr[ 10 ]; } str1 ; struct varchar_2 { int len; char arr[ 20 ]; } str2 ; struct varchar_3 { int len; char arr[ 30 ]; } str3 ; thus losing the storage attribute for the later variables. Repeat the declaration for each such variable. (Note that this occurred only for variables declared "varchar" or "bytea", which may help explain how it escaped detection for so long.) Andrey Sokolov Discussion: https://postgr.es/m/942241662288242@mail.yandex.ru
* Doc: improve documentation about where the psqlrc files are.Tom Lane2022-09-09
| | | | | | | | | | | | | | | | | | | | Remove no-longer-accurate claim that Windows lacks home directories. Clarify the text by more clearly distinguishing which statements reflect hard-wired choices versus which ones reflect overridable defaults. Update the examples of version-specific file names, and make them track future version changes by using "&majorversion;" and "&version;". (BTW, in devel and beta releases this method correctly says that you can use strings like "16devel" and "15beta4" as minor version identifiers.) Back-patch to v15, but not further, with the thought that in older releases the examples with three-part version numbers still had some historical relevance. v15 will be the first major release after the last 9.x branch went out of support. Robert Treat and Tom Lane, reviewed by Julien Rouhaud Discussion: https://postgr.es/m/CAJSLCQ07F-WCYYYOY8+dWhHcVeJ1Pb01cWc-c0Hu=M3EjKT2Eg@mail.gmail.com
* Reject bogus output from uuid_create(3).Tom Lane2022-09-09
| | | | | | | | | | | | | | | | | | | | | | When using the BSD UUID functions, contrib/uuid-ossp expects uuid_create() to produce a version-1 UUID. FreeBSD still does so, but in recent NetBSD releases that function produces a version-4 (random) UUID instead. That's not acceptable for our purposes: if the user wanted v4 she would have asked for v4, not v1. Hence, check the version digit and complain if it's not '1'. Also drop the documentation's claim that the NetBSD implementation is usable. It might be, depending on which OS version you're using, but we're not going to get into that kind of detail. (Maybe someday we should ditch all these external libraries and just write our own UUID code, but today is not that day.) Nazir Bilal Yavuz, with cosmetic adjustments and docs by me. Backpatch to all supported versions. Discussion: https://postgr.es/m/3848059.1661038772@sss.pgh.pa.us Discussion: https://postgr.es/m/17358-89806e7420797025@postgresql.org
* Doc fixes for MERGE statementAlvaro Herrera2022-09-09
| | | | | | | | | | | | | | | | In commit 3d895bc846f2 I introduced a bogus semicolon mid-statement by careless cut-n-paste; move it. This had already been reported by Justin Pryzby. Also, change the styling a bit by avoiding names in CamelCase. This is more consistent with the style we use elsewhere. Backpatch to 15. Author: Vitaly Burovoy <vitaly.burovoy@gmail.com> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/9afe5766-5a61-7860-598c-136867fad065@gmail.com Discussion: https://postgr.es/m/20220819133016.GV26426@telsasoft.com
* Fix GetForeignKey*Triggers for self-referential FKsAlvaro Herrera2022-09-09
| | | | | | | | | | | | | | | | | | | | Because of inadequate filtering, the check triggers were confusing the search for action triggers in GetForeignKeyActionTriggers and vice-versa in GetForeignKeyCheckTriggers; this confusion results in seemingly random assertion failures, and can have real impact in non-asserting builds depending on catalog order. Change these functions so that they correctly ignore triggers that are not relevant to each side. To reduce the odds of further problems, do not break out of the searching loop in assertion builds. This break is likely to hide bugs; without it, we would have detected this bug immediately. This problem was introduced by f4566345cf40, so backpatch to 15 where that commit first appeared. Author: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220908172029.sejft2ppckbo6oh5@awork3.anarazel.de Discussion: https://postgr.es/m/4104619.1662663056@sss.pgh.pa.us
* Bump minimum version of Flex to 2.5.35John Naylor2022-09-09
| | | | | | | | Since the retirement of some older buildfarm members, the oldest Flex that gets regular testing is 2.5.35. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/1097762.1662145681@sss.pgh.pa.us
* Bump minimum version of Bison to 2.3John Naylor2022-09-09
| | | | | | | | | | | | Since the retirement of some older buildfarm members, the oldest Bison that gets regular testing is 2.3. MacOS ships that version, and will continue doing so for the forseeable future because of Apple's policy regarding GPLv3. While Mac users could use a package manager to install a newer version, there is no compelling reason to force them do so at this time. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/1097762.1662145681@sss.pgh.pa.us
* Add jsonpath_gram.h to list of distprep targetsJohn Naylor2022-09-09
| | | | Oversight in dac048f71e
* Replace load of functions by direct calls for some WIN32Michael Paquier2022-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the following code paths to do direct system calls to some WIN32 functions rather than loading them from an external library, shaving some code in the process: - Creation of restricted tokens in pg_ctl.c, introduced by a25cd81. - QuerySecurityContextToken() in auth.c for SSPI authentication in the backend, introduced in d602592. - CreateRestrictedToken() in src/common/. This change is similar to the case of pg_ctl.c. Most of these functions were loaded rather than directly called because, as mentioned in the code comments, MinGW headers were not declaring them. I have double-checked the recent MinGW code, and all the functions changed here are declared in its headers, so this change should be safe. Note that I do not have a MinGW environment at hand so I have not tested it directly, but that MSVC was fine with the change. The buildfarm will tell soon enough if this change is appropriate or not for a much broader set of environments. A few code paths still use GetProcAddress() to load some functions: - LDAP authentication for ldap_start_tls_sA(), where I am not confident that this change would work. - win32env.c and win32ntdll.c where we have a per-MSVC version dependency for the name of the library loaded. - crashdump.c for MiniDumpWriteDump() and EnumDirTree(), where direct calls were not able to work after testing. Reported-by: Thomas Munro Reviewed-by: Justin Prysby Discussion: https://postgr.es/m/CA+hUKG+BMdcaCe=P-EjMoLTCr3zrrzqbcVE=8h5LyNsSVHKXZA@mail.gmail.com
* Add more error context to RestoreBlockImage() and consume itMichael Paquier2022-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | On failure in restoring a block image, no details were provided, while it is possible to see failure with an inconsistent record state, a failure in processing decompression or a failure in decompression because a build does not support this option. RestoreBlockImage() is used in two code paths in the backend code, during recovery and when checking a page consistency after applying masking, and both places are changed to consume the error message produced by the internal routine when it returns a false status. All the error messages are reported under ERRCODE_INTERNAL_ERROR, that gets used also when attempting to access a page compressed by a method not supported by the build attempting the decompression. This is something that can happen in core when doing physical replication with primary and standby using inconsistent build options, for example. This routine is available since 2c03216d and it has never provided any context about the error happening when it failed. This change is justified even more after 57aa5b2, that introduced compression of FPWs in WAL. Reported-by: Justin Prysby Author: Michael Paquier Discussion: https://postgr.es/m/20220905002320.GD31833@telsasoft.com Backpatch-through: 15
* Instrument freezing in autovacuum log reports.Peter Geoghegan2022-09-08
| | | | | | | | | | | Add a new line to log reports from autovacuum (as well as VACUUM VERBOSE output) that shows information about freezing. Emphasis is placed on the total number of heap pages that had one or more tuples frozen by VACUUM. The total number of tuples frozen is also shown. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Jeff Janes <jeff.janes@gmail.com> Discussion: https://postgr.es/m/CAH2-WznTY6D0zyE8VLrC6Gd4kh_HGAXxnTPtcOQOOsxzLx9zog@mail.gmail.com
* Temporarily make MemoryContextContains return falseDavid Rowley2022-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5265e91fd changed MemoryContextContains to update it so that it works correctly with the new MemoryChunk code added in c6e0fe1f2. However, 5265e91fd was done with the assumption that MemoryContextContains would only ever be given pointers to memory that had been returned by one of our MemoryContext allocators. It seems that's not true and many of our 32-bit buildfarm animals are clearly showing that. There are some code paths that call MemoryContextContains with a pointer pointing part way into an allocated chunk. The example of this found by the 32-bit buildfarm animals is the int2int4_sum() function. This function returns transdata->sum, which is not a pointer to memory that was allocated directly. This return value is then subsequently passed to MemoryContextContains which causes it to crash due to it thinking the memory directly prior to that pointer is a MemoryChunk. What's actually in that memory is the field in the struct that comes prior to the "sum" field. This problem didn't occur in 64-bit world because BIGINT is a byval type and the code which was calling MemoryContextContains with the bad pointer only does so with non-byval types. Here, instead of reverting 5265e91fd and making MemoryContextContains completely broken again, let's just make it always return false for now. Effectively prior to 5265e91fd it was doing that anyway, this at least makes that more explicit. The only repercussions of this with the current MemoryContextContains calls are that we perform a datumCopy() when we might not need to. This should make the 32-bit buildfarm animals happy again and give us more time to consider a long-term fix. Discussion: https://postgr.es/m/20220907130552.sfjri7jublfxyyi4%40jrouhaud
* Choose FK name correctly during partition attachmentAlvaro Herrera2022-09-08
| | | | | | | | | | | | | | | During ALTER TABLE ATTACH PARTITION, if the name of a parent's foreign key constraint is already used on the partition, the code tries to choose another one before the FK attributes list has been populated, so the resulting constraint name was "<relname>__fkey" instead of "<relname>_<attrs>_fkey". Repair, and add a test case. Backpatch to 12. In 11, the code to attach a partition was not smart enough to cope with conflicting constraint names, so the problem doesn't exist there. Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com> Discussion: https://postgr.es/m/20220901184156.738ebee5@karst
* Fix recovery_prefetch with low maintenance_io_concurrency.Thomas Munro2022-09-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | We should process completed IOs *before* trying to start more, so that it is always possible to decode one more record when the decoded record queue is empty, even if maintenance_io_concurrency is set so low that a single earlier WAL record might have saturated the IO queue. That bug was hidden because the effect of maintenance_io_concurrency was arbitrarily clamped to be at least 2. Fix the ordering, and also remove that clamp. We need a special case for 0, which is now treated the same as recovery_prefetch=off, but otherwise the number is used directly. This allows for testing with 1, which would have made the problem obvious in simple test scenarios. Also add an explicit error message for missing contrecords. It was a bit strange that we didn't report an error already, and became a latent bug with prefetching, since the internal state that tracks aborted contrecords would not survive retrying, as revealed by 026_overwrite_contrecord.pl with this adjustment. Reporting an error prevents that. Back-patch to 15. Reported-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20220831140128.GS31833%40telsasoft.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 23:17:19 +0000