pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Document limit on the number of out-of-line values per table

Document limit on the number of out-of-line values per table Document the hard limit stemming from the size of an OID, and also mention the perfomance impact that occurs before the hard limit is reached. Jakub Wartak and Robert Haas Backpatch to all supported versions Discussion: https://postgr

pgsql: Lower minimum maintenance_work_mem to 64kB

Lower minimum maintenance_work_mem to 64kB Since the introduction of TID store, vacuum uses far less memory in the common case than in versions 16 and earlier. Invoking multiple rounds of index vacuuming in turn requires a much larger table. It'd be a good idea anyway to cover this case in regress

pgsql: Lower minimum maintenance_work_mem to 64kB

Lower minimum maintenance_work_mem to 64kB Since the introduction of TID store, vacuum uses far less memory in the common case than in versions 16 and earlier. Invoking multiple rounds of index vacuuming in turn requires a much larger table. It'd be a good idea anyway to cover this case in regress

pgsql: Prevent access of uninitialized memory in radix tree nodes

Prevent access of uninitialized memory in radix tree nodes RT_NODE_16_SEARCH_EQ() performs comparisions using vector registers on x64-64 and aarch64. We apply a mask to the resulting bitfield to eliminate irrelevant bits that may be set. This ensures correct behavior, but Valgrind complains of the

pgsql: Small cosmetic fixes in radix tree template

Small cosmetic fixes in radix tree template - Bring memory context names in line with other naming - Fix typos, reported off-list by Alexander Lakhin - Remove copy-paste errors from comments - Remove duplicate #undef Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e

pgsql: Fix make headerscheck

Fix make headerscheck In the wake of commits dac048f71 and ecaf7c5df, `make headerscheck` no longer generated all headers that are included by other headers, causing headerscheck/cpluspluscheck to fail. To fix, backpatch enough makefile rules from 721856ff2 to generate all required headers. Repor

pgsql: Get rid of anonymous struct

Get rid of anonymous struct This is a C11 feature, and we require C99. While at it, go the further step and get rid of the surrounding union (with uintptr_t) entirely, as there is currently no use case for this file to access the header of BlocktableEntry as a uintptr_t, and there are no additiona

Re: pgsql: Teach radix tree to embed values at runtime

On Tue, Apr 9, 2024 at 12:27 AM Andres Freund wrote: > > This isn't quite C99 conformant, and thus breaks on the buildfarm animal > set up to test that: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-04-08%2012%3A07%3A01 I haven't forgotten about this and will fix withi

pgsql: Teach radix tree to embed values at runtime

Teach radix tree to embed values at runtime Previously, the decision to store values in leaves or within the child pointer was made at compile time, with variable length values using leaves by necessity. This commit allows introspecting the length of variable length values at runtime for that deci

pgsql: Teach TID store to skip bitmap for small numbers of offsets

Teach TID store to skip bitmap for small numbers of offsets The header portion of BlocktableEntry has enough padding space for an array of 3 offsets (1 on 32-bit platforms). Use this space instead of having a sparse bitmap array. This will take up a constant amount of space no matter what the offs

pgsql: Use bump context for TID bitmaps stored by vacuum

Use bump context for TID bitmaps stored by vacuum Vacuum does not pfree individual entries, and only frees the entire storage space when finished with it. This allows using a bump context, eliminating the chunk header in each leaf allocation. Most leaf allocations will be 16 to 32 bytes, so that's

pgsql: Fix alignment of stack variable

Fix alignment of stack variable Declare with union similar to PGAlignedBlock. Report and fix by Andres Freund Discussion: https://postgr.es/m/20240407190731.izm3mdazednrsiqk%40awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0ea51bac3802dca9dcf5

pgsql: Teach fasthash_accum to use platform endianness for bytewise loa

Teach fasthash_accum to use platform endianness for bytewise loads This function previously used a mix of word-wise loads and bytewise loads. The bytewise loads happened to be little-endian regardless of platform. This in itself is not a problem. However, a future commit will require the same resu

pgsql: Speed up tail processing when hashing aligned C strings, take tw

Speed up tail processing when hashing aligned C strings, take two After encountering the NUL terminator, the word-at-a-time loop exits and we must hash the remaining bytes. Previously we calculated the terminator's position and re-loaded the remaining bytes from the input string. This was slower t

pgsql: Add macro to disable address safety instrumentation

Add macro to disable address safety instrumentation fasthash_accum_cstring_aligned() uses a technique, found in various strlen() implementations, to detect a string's NUL terminator by reading a word at at time. That triggers failures when testing with "-fsanitize=address", at least with frontend

pgsql: Fix incorrect return type

Fix incorrect return type fasthash32() calculates a 32-bit hashcode, but the return type was uint64. Change to uint32. Noted by Jeff Davis Discussion: https://postgr.es/m/b16c93e6c736a422d4de668343515375664eb05d.camel%40j-davis.com Branch -- master Details --- https://git.postgresql.o

pgsql: Convert uses of hash_string_pointer to fasthash equivalent

Convert uses of hash_string_pointer to fasthash equivalent Remove duplicate hash_string_pointer() function definitions by creating a new inline function hash_string() for this purpose. This has the added advantage of avoiding strlen() calls when doing hash lookup. It's not clear how many of these

pgsql: Revert "Speed up tail processing when hashing aligned C strings"

Revert "Speed up tail processing when hashing aligned C strings" This reverts commit 07f0f6abfc7f6c55cede528d9689dedecefc734a. This has shown failures on both Valgrind and big-endian machines, per members skink and pike. Branch -- master Details --- https://git.postgresql.org/pg/commitd

Re: pgsql: Speed up tail processing when hashing aligned C strings

On Sun, Mar 31, 2024 at 12:32 PM John Naylor wrote: > > Speed up tail processing when hashing aligned C strings Skink reports valgrind error with Conditional jump or move depends on uninitialised value(s) I'll revert this soon to analyze, but first I'd like to see if any bi

pgsql: Speed up tail processing when hashing aligned C strings

shortening the dependency chain. Ants Aasma and John Naylor Discussion: https://postgr.es/m/CANwKhkP7pCiW_5fAswLhs71-JKGEz1c1%2BPC0a_w1fwY4iGMqUA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07f0f6abfc7f6c55cede528d9689dedecefc734a

Re: pgsql: Add TIDStore, to store sets of TIDs (ItemPointerData) efficientl

On Tue, Mar 26, 2024 at 9:36 AM Masahiko Sawada wrote: > > On Tue, Mar 26, 2024 at 7:16 AM David Rowley wrote: > > > > Either "max_bytes" is a bad name for this variable or the * 1024L > > should be removed. > > > > Right. We discussed it on the original thread too[1]. Since we're > going to chan

Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:43 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 16:37, John Naylor wrote: > > Thanks, I was getting close to committing a hackish workaround -- this > > seems better! > > ok cool. I also noticed a typo. Maybe worth fixing that at the same t

pgsql: Revert "Fix link error for test_radixtree module on Windows"

Revert "Fix link error for test_radixtree module on Windows" This reverts commit 9552e3ace317ac8bb0a80613c0e5cd6536c96dc8. I (john) forgot to revert this locally when a more principled fix was found, which has the same message title. Branch -- master Details --- https://git.postgresql.o

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add PGDLLIMPORT to pg_popcount32/64. In passing, fix a typo. Diagnosis by Masahiko Sawada, patch by David Rowley Per buildfarm members drongo and fairywren Discussion: https://postgr.es/m/CAD21AoAMm1mQd%3Dw4PrfrKK%3DOMP8j8%3D7ntJRPF8%2B%3D10i

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add back "link_with" directive, similar to the one removed by 1f1d73a8b, but only for Windows, but use the "_shlib" variation. Diagnosis by Masahiko Sawada, proposed fix adjusted and tested by me Per buildfarm members drongo and fairywren Disc

Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:29 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 13:48, John Naylor wrote: > > Now, after I get some coffee I'll look into the Windows failures. > > I had a look at this and the attached fixes the broken build on MSVC for me. > > I

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:47 PM John Naylor wrote: > > On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > > > Well, surely we can email them. Their profiles show they're still > > active. > > https://db.in.tum.de/people/sites/kemper/?lang=en > >

pgsql: Blind attempt to fix ODR violations

Blind attempt to fix ODR violations Remove apparently useless "link_with" directive. Even if this isn't the root cause, it makes the .build file more like the other test modules. Reviewed by Masahiko Sawada Follow-up to ee1b30f12, per buildfarm members olingo and grassquit. Discussion: https:/

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > Well, surely we can email them. Their profiles show they're still > active. > https://db.in.tum.de/people/sites/kemper/?lang=en > https://db.in.tum.de/people/sites/neumann/?lang=en > https://db.in.tum.de/people/sites/leis/?lang=en I though

pgsql: Fix incorrect format specifier for int64

Fix incorrect format specifier for int64 Follow-up to ee1b30f12, per buildfarm member mamba. Discussion: https://postgr.es/m/CANWCAZYwyRMU%2BOTVOjK%3Dno1hm-W3ZQ5vrSFM1MFAaLtLydvwzA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e444ebcb85c0b55b1c

pgsql: Fix redefinition of typedefs

Fix redefinition of typedefs Per buildfarm members sifaka and longfin, clang with -Wtypedef-redefinition warns of duplicate typedefs unless building with C11. Follow-up to ee1b30f12. Masahiko Sawada Discussion: https://postgr.es/m/CANWCAZauSg%3DLUbBbXhpeQtBuPifmzQNTYS6O8NsoAPz1zL-Txg%40mail.gma

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 1:32 PM Tom Lane wrote: > > John Naylor writes: > > On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > >> Hm ... do we know that this is not patent-encumbered technology? > >> Commits citing such specific prior art make me nervous. >

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 1:08 PM Tom Lane wrote: > > John Naylor writes: > > This implements a radix tree data structure based on the design in > > "The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases" > > by Viktor Leis, Alfons Kemper, and ThomasNe

pgsql: Add template for adaptive radix tree

n in the same manner as simplehash.h and sort_template.h. Future commits will use this infrastructure for storing TIDs. Patch by Masahiko Sawada and John Naylor, but a substantial amount of credit is due to Andres Freund, whose proof-of-concept was a valuable source of coding idioms and awa

pgsql: Fix signedness error in 9f225e992 for gcc

Fix signedness error in 9f225e992 for gcc The first argument of vshrq_n_s8 needs to be a signed vector type, but it was passed unsigned. Clang is more lax with conversion, but gcc needs a cast. Fix by me, tested by Masahiko Sawada Per buildfarm members splitfin, batta, widowbird, snakefly, parul

pgsql: Introduce helper SIMD functions for small byte arrays

Introduce helper SIMD functions for small byte arrays vector8_min - helper for emulating ">=" semantics vector8_highbit_mask - used to turn the result of a vector comparison into a bitmask Masahiko Sawada Reviewed by Nathan Bossart, with additional adjustments by me Discussion: https://postgr.

pgsql: Move some bitmap logic out of bitmapset.c

Move some bitmap logic out of bitmapset.c Move the logic for selecting appropriate pg_bitutils.h functions based on word size to bitmapset.h for wider visibility. Reviewed (in a previous version) by Tom Lane Discussion: https://postgr.es/m/CAFBsxsFW2JjTo58jtDB%2B3sZhxMx3t-3evew8%3DAcr%2BGGhC%2Bk

pgsql: Fix warnings in cpluspluscheck

Fix warnings in cpluspluscheck Various int variables were compared to macros that are of type size_t, which caused -Wsign-compare warnings in cpluspluscheck. Change those to size_t, which also better describes their purpose. Per report from Peter Eisentraut Discussion: https://postgr.es/m/4868

pgsql: Further cosmetic review of hashfn_unstable.h

Further cosmetic review of hashfn_unstable.h In follow-up to e97b672c8, * Flesh out comments explaining the incremental interface * Clarify detection of zero bytes when hashing aligned C strings The latter was suggested and reviewed by Jeff Davis Discussion: https://postgr.es/m/48e8f8bbe0be9c78

pgsql: Simplify initialization of incremental hash state

Simplify initialization of incremental hash state The standalone functions fasthash{32,64} use length for two purposes: how many bytes to hash, and how to perturb the internal seed. Developers using the incremental interface may not know the length ahead of time (e.g. for C strings). In this case

pgsql: Fixed misspelled byteswap function for big endian machines

Fixed misspelled byteswap function for big endian machines Per members lora and mamba Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd0a0cfc81fecacf2aed41b9eb138f850e43aab6 Modified Files -- src/include/common/hashfn_unstable.h | 2 +- 1 file changed,

pgsql: Add optimized C string hashing

ce that is written in assembly language. As demonstration, use this in the search path cache. This brings the general case performance closer to the special case optimization done in commit a86c61c9ee. There are other places that could benefit, but that is left for future work. Jeff Davis and J

pgsql: Add inline incremental hash functions for in-memory use

Add inline incremental hash functions for in-memory use It can be useful for a hash function to expose separate initialization, accumulation, and finalization steps. In particular, this is useful for building inline hash functions for simplehash. Instead of trying to whack around hash_bytes whil

pgsql: Update documentation of default fdw_tuple_cost

Update documentation of default fdw_tuple_cost Follow up to cac169d68 Umair Shahid Reviewed by Richard Guo and Chris Travers Discussion: https://postgr.es/m/CALVUYo9RECc5gwD%2B4SRM5Es%2Bbg9cpNfhd3_qUjf7kVTGyLpFJg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.or

pgsql: Fix typo and case in messages

Fix typo and case in messages Follow up to dc2123400 Kyotaro Horiguchi Discussion: https://postgr.es/m/20231222.154939.1509525390095583358.horikyota@gmail.com Discussion: https://postgr.es/m/20231225.145124.1745560266993421173.horikyota@gmail.com Branch -- master Details ---

pgsql: Remove redundant setting of hashkey after insertion

Remove redundant setting of hashkey after insertion It's not necessary to fill the key field in most cases, since hash_search has already done that. Some existing call sites have an assert or comment that this contract has been fulfilled, but those are quite old and that practice seems unnecessary

Re: pgsql: Split out tiebreaker comparisons from comparetup_* functions

ures > seem different, and there are also now some failures in release > branches that don't have your commit, so I'd wait long for more > evidence... Ah, I did check at least one back branch yesterday and didn't see any failures then. I see them now, thanks! (FWIW, I've

Re: pgsql: Split out tiebreaker comparisons from comparetup_* functions

On Thu, Aug 17, 2023 at 11:41 AM John Naylor wrote: > > > On Wed, Aug 16, 2023 at 5:17 PM John Naylor wrote: > > > > Split out tiebreaker comparisons from comparetup_* functions > > Hammerkop is getting OOM errors with this change. Most grand totals in the memory conte

Re: pgsql: Split out tiebreaker comparisons from comparetup_* functions

On Wed, Aug 16, 2023 at 5:17 PM John Naylor wrote: > > Split out tiebreaker comparisons from comparetup_* functions Hammerkop is getting OOM errors with this change. Most grand totals in the memory context stats show between 1 and 3 MB, and "tuplesort main" only shows small-ish

pgsql: Split out tiebreaker comparisons from comparetup_* functions

Split out tiebreaker comparisons from comparetup_* functions Previously, if a specialized comparator found equal datum1 keys, the "comparetup" function would repeat the comparison on the datum before proceeding with the unabbreviated first key and/or additional sort keys. Move comparing additiona

pgsql: Update Solution.pm for new LoongArch CRC symbol

Update Solution.pm for new LoongArch CRC symbol Oversight in 4d14ccd6a, per report from Amit Kapila and Michael Paquier. Discussion: https://postgr.es/m/CAA4eK1LsV3KuyUt8tzZDjPcUds1XfVVeW3Wpeju_59DtRV0%3DxQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/com

pgsql: Use native CRC instructions on 64-bit LoongArch

Use native CRC instructions on 64-bit LoongArch As with the Intel and Arm CRC instructions, compiler intrinsics for them must be supported by the compiler. In contrast, no runtime check is needed. Aligned memory access is faster, so use the Arm coding as a model. YANG Xudong Discussion: https:/

pgsql: Bring some MSVC asserts in line with other platforms

Bring some MSVC asserts in line with other platforms MSVC's _BitScan* functions return a boolean indicating whether any bits were set in the input, and we were previously asserting that they returned true, per our API. This is correct. However, other platforms simply assert that the input is non-z

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eac34f7eb3153

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/790be6f31e6ae

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ba8fd17be04a7

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/72e78727124ff

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f5d60b1ea2156

pgsql: doc: Update error messages in RLS examples

doc: Update error messages in RLS examples Since 8b9e9644d, the messages for failed permissions checks report "table" where appropriate, rather than "relation". Backpatch to all supported branches Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/542b6347bf8876d89146

pgsql: Remove newly added asserts from pg_bitutils.h

Remove newly added asserts from pg_bitutils.h These were valuable during development, but are unlikely to tell us anything going forward. This reverts 204b0cbec and adjusts the content of 677319746 to more closely match the more-readable original style. Per review from Tom Lane Discussion: http

Re: pgsql: Add assert checking to pg_leftmost_one_pos32() and friends

On Tue, Feb 21, 2023 at 11:59 AM John Naylor wrote: > > On Mon, Feb 20, 2023 at 10:17 PM Tom Lane wrote: > > > > John Naylor writes: > > > Add assert checking to pg_leftmost_one_pos32() and friends > > > > I can see that this was worth writing for testi

Re: pgsql: Add assert checking to pg_leftmost_one_pos32() and friends

On Mon, Feb 20, 2023 at 10:17 PM Tom Lane wrote: > > John Naylor writes: > > Add assert checking to pg_leftmost_one_pos32() and friends > > I can see that this was worth writing for testing purposes, but > is it really worth carrying permanently? Even in a debug build,

pgsql: Add MSVC support for pg_leftmost_one_pos32() and friends

Add MSVC support for pg_leftmost_one_pos32() and friends To allow testing for general support for fast bitscan intrinsics, add symbols HAVE_BITSCAN_REVERSE and HAVE_BITSCAN_FORWARD. Also do related cleanup in AllocSetFreeIndex(): Previously, we tested for HAVE__BUILTIN_CLZ and copied the relevant

pgsql: Add assert checking to pg_leftmost_one_pos32() and friends

Add assert checking to pg_leftmost_one_pos32() and friends Discussion: https://www.postgresql.org/message-id/CAFBsxsEPc%2BFnX_0vmmQ5DHv60sk4rL_RZJ%2BMD6ei%3D76L0kFMvA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/204b0cbecb82ab3fde2e12998a89e7227

pgsql: Remove redundant relkind check

Remove redundant relkind check Ranier Vilela Reviewed by Justin Pryzby Discussion: https://www.postgresql.org/message-id/CAEudQAp2R2fbbi0OHHhv_n4%3DCh0t1VtjObR9YMqtGKHJ%2BfaUFQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/15eb1228800a35042ef318

pgsql: Remove dead code in formatting.c

Remove dead code in formatting.c Remove some code guarded by IS_MINUS() or IS_PLUS(), where the entire stanza is inside an else-block where both of these are false. This should slightly improve test coverage. While at it, remove coding that apparently assumes that unsetting a bit is so expensive

pgsql: Remove redundant setting of tuplesort status

Remove redundant setting of tuplesort status Also add an explanatory comment to match other similar coding within tuplesort_performsort(). Xing Guo Reviewed by Richard Guo and Cary Huang Discussion: https://www.postgresql.org/message-id/CACpMh%2BAQ4GXRKKi9ib2ioUH%2BqwNaSAVbetssJ0tMPfxAWuL2yg%40

pgsql: Move variable increment to the end of the loop

Move variable increment to the end of the loop This is less error prone and matches the placement of other code in the file. Justin Pryzby Reviewed by Tom Lane Discussion: https://www.postgresql.org/message-id/20221123172436.gj11...@telsasoft.com Branch -- master Details --- https://g

pgsql: Remove outdated include

Remove outdated include In the wake of bfb9dfd93, there are no longer any stat() calls in guc-file.l, but the work leading to dac048f71 did not get the memo. Noted by Michael Paquier Discussion: https://www.postgresql.org/message-id/Y2OosGi1Xh9x/lEn%40paquier.xyz Branch -- master Details -

Re: pgsql: Straighten include order in guc-file.l

On Thu, Nov 3, 2022 at 12:39 PM John Naylor wrote: > https://git.postgresql.org/pg/commitdiff/062eef3a9bbd5da9c26c93127ee6272193cb06e6 flaviventris fails on the pg_resetwal test with "initdb: error: invalid locale settings; check LANG and LC_* environment variables", and idiacan

pgsql: Straighten include order in guc-file.l

Straighten include order in guc-file.l Oversight in dac048f71eb Michael Paquier Reviewed by Julien Rouhaud Discussion: https://www.postgresql.org/message-id/Y2IATvRGo347Lvd1%40paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/062eef3a9bbd5da9c26c93127ee6

pgsql: Remove unnecessary semicolons after goto labels

Remove unnecessary semicolons after goto labels According to the C standard, a label must followed by a statement. If there was ever a time we needed an empty statement here, it was a long time ago. Japin Li Reviewed by Julien Rouhaud Discussion: https://www.postgresql.org/message-id/MEYP282MB1

pgsql: Fix typos referring to PGPROC

Fix typos referring to PGPROC Japin Li Reviewed by Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/meyp282mb1669459813b36fb5eaa38434b6...@meyp282mb1669.ausp282.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/08f8af983a8bd8ef78e

pgsql: Fix grammar in error message

Fix grammar in error message While at it, make ellipses formatting consistent when describing SQL statements. Ekaterina Kiryanova and Alexander Lakhin Reviewed by myself and Álvaro Herrera Discussion: https://www.postgresql.org/message-id/eed5cec0-a542-53da-6a5e-7789c6ed9817%40postgrespro.ru Ba

pgsql: Fix grammar in error message

Fix grammar in error message While at it, make ellipses formatting consistent when describing SQL statements. Ekaterina Kiryanova and Alexander Lakhin Reviewed by myself and Álvaro Herrera Discussion: https://www.postgresql.org/message-id/eed5cec0-a542-53da-6a5e-7789c6ed9817%40postgrespro.ru Ba

pgsql: Blind attempt to fix LLVM dependency in the backend

Blind attempt to fix LLVM dependency in the backend Commit ecaf7c5df5 removed gram.h from the backend's generated-headers target. In LLVM builds, this leads to loss of dependency information when generating .bc files. To fix, add a rule that mirrors ad-hoc .o dependencies for .bc files as well. P

Re: pgsql: Move gramparse.h to src/backend/parser

ind attempt since it seems sporadic and doesn't happen to reproduce for me. -- John Naylor EDB: http://www.enterprisedb.com

pgsql: Fix failure to build gramparse.h standalone in vpath builds

Fix failure to build gramparse.h standalone in vpath builds Add include directory in a similar fashion as 829906fb6c. Per buildfarm animal crake Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b0526d271d16d54064666d30bbfa53d4f335c66d Modified Files --

Re: pgsql: Move gramparse.h to src/backend/parser

On Wed, Sep 14, 2022 at 11:02 AM John Naylor wrote: > > Move gramparse.h to src/backend/parser Member crake doesn't like this. I thought I tried vpath for this patch, but I'll go confirm now. -- John Naylor EDB: http://www.enterprisedb.com

pgsql: Bump minimum Perl version to 5.14

Bump minimum Perl version to 5.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

pgsql: Move gramparse.h to src/backend/parser

Move gramparse.h to src/backend/parser 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 fr

pgsql: Adjust header exceptions for 0bd9c6297

Adjust header exceptions for 0bd9c6297 Per buildfarm animal crake Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fcf7b3a9d42c3cf778dab0fc644f11f12684d184 Modified Files -- src/tools/pginclude/cpluspluscheck | 2 +- src/tools/pginclude/headerscheck | 2

Re: pgsql: Fix perltidy breaking perlcritic

on the fact > that eval returns the value of the last expression in the string, which > also gets rid of the ugly quoting and escaping, per the attached. Hmm, interesting. -- John Naylor EDB: http://www.enterprisedb.com

pgsql: Treat Unicode codepoints of category "Format" as non-spacing

Treat Unicode codepoints of category "Format" as non-spacing 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 coverag

pgsql: Make eval statement naturally proof against perltidy

Make eval statement naturally proof against perltidy 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_S4ayH2sW

Re: pgsql: Fix perltidy breaking perlcritic

c respects block boundaries for its directives. I tried that in the attached -- it looks a bit nicer but requires more explanation. I don't have strong feelings either way. -- John Naylor EDB: http://www.enterprisedb.com diff --git a/src/backend/catalog/Catalog.pm b/src/backend/catalog/Catalog

Re: pgsql: Choose FK name correctly during partition attachment

&dt=2022-09-08%2015%3A30%3A25 I'm seeing a lot more failures now after the Flex/Bison minimum version bump, but that's a strange correlation. Maybe the above failure is intermittent? -- John Naylor EDB: http://www.enterprisedb.com

pgsql: Bump minimum version of Flex to 2.5.35

Bump minimum version of Flex to 2.5.35 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.1662145...@sss.pgh.pa.us Branch -- master Details --- ht

pgsql: Bump minimum version of Bison to 2.3

Bump minimum version of Bison to 2.3 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 packag

pgsql: Add jsonpath_gram.h to list of distprep targets

Add jsonpath_gram.h to list of distprep targets Oversight in dac048f71e Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/96683db880cab7791006fcc13416d67f6230a2f7 Modified Files -- src/backend/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Add b2e6e7682 to .git-blame-ignore-revs

Add b2e6e7682 to .git-blame-ignore-revs Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b289b86231ad10fb317231ff85596d6272203916 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)

pgsql: Run perltidy over Catalog.pm

Run perltidy over Catalog.pm Commit 69eb643b2 deliberately left indentation unchanged to make the changes more legible. Rather than waiting until next year's perltidy run, do it now to avoid confusion Per suggestion from Álvaro Herrera Discussion: https://www.postgresql.org/message-id/2022090708

pgsql: Parse catalog .dat files as a whole when compiling the backend

Parse catalog .dat files as a whole when compiling the backend Previously Catalog.pm eval'd each individual hash reference so that comments and whitespace can be preserved when running reformat-dat-files. This is unnecessary when building, and we can save ~15% off the run time of genbki.pl by simp

pgsql: Fix cplusplusscheck in vpath builds

Fix cplusplusscheck in vpath builds Same solution as 829906fb6. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cec2754fbebee0a40aaf905947deb823cca4fe39 Modified Files -- src/tools/pginclude/cpluspluscheck | 2 ++ 1 file changed, 2 insertions(+)

  1   2   3   >