Re: Use bsearch() instead of a manual binary search in syscache.c

Hi, Thanks for the explanation which helps me a lot! The bsearch() got inlined according to compiler explorer: https://godbolt.org/z/1x69zGMcn So we'd probably need our own inline function to keep the playing field level.  Some tweaked algorithms[1] are also said to speed up small integer t

Re: pg_dump not dumping default_text_search_config WAI?

On 2025-11-09 04:06, Tom Lane wrote: > Philip Warner writes: >> I just got bitten by dumping and restoring a database to a new cluster, >> and the default_text_search_config was not copied for the database. > >> A check of the dump file shows no 'ALTER DATABASE' command. > > IIRC you'd need to

Re: MSVC: Improve warning options set

Hi, On November 8, 2025 4:40:26 PM EST, Thomas Munro wrote: >On Tue, Nov 4, 2025 at 7:56 AM Peter Eisentraut wrote: >> On 31.10.25 14:31, Bryan Green wrote: >> > The real question is MinGW. If we still support MinGW builds targeting >> > the old MSVCRT, those need the environ declaration. If we

Re: Add tab completion support for WAIT FOR command

Hi Alexander, On Sat, Nov 8, 2025 at 7:33 PM Alexander Korotkov wrote: > > Hi, Xuneng! > > On Fri, Nov 7, 2025 at 12:10 PM Xuneng Zhou wrote: > > The WAIT FOR command was committed in 447aae1; this patch has been > > updated to match its grammar. > > I made minor adjustments to the patch. I'm g

Re: Use bsearch() instead of a manual binary search in syscache.c

On Sun, Nov 9, 2025 at 6:01 AM Tom Lane wrote: > I'm quite certain that years ago we determined that bsearch() > was slower than a manually written-out loop, probably because of > exactly the point that the comparisons would be inline. Don't > know whether modern compilers have changed that concl

Re: MSVC: Improve warning options set

On Sun, Nov 9, 2025 at 10:58 AM Tom Lane wrote: > I don't quite understand how 1758d4244 didn't break building with > MSVCRT? But if it builds yet doesn't in fact work, that's likely to > draw complaints from people who didn't spot the documentation change. I think it links against MinGW shims t

Re: Extend injection_points_attach() to accept a user-defined function

On Fri, Nov 07, 2025 at 05:39:57PM +0530, Rahila Syed wrote: > OK, it makes sense to leave it out of this function for now. Since > pgstat_create_inj() currently only tracks the number of runs, it also > depends on any callback using the appropriate pgstat_report_* API > from the injection_point mo

Re: [PATCH] Fix text in comment of copyto.c

On Sat, Nov 08, 2025 at 02:12:35PM +0900, 河田達也 wrote: > This patch fixes a missed correction in a comment in vacuum.c. > The word "cstate for COPY TO/FROM" was corrected to "cstate for COPY TO". Fixed, thanks. -- Michael signature.asc Description: PGP signature

Re: relfilenode statistics

On Fri, Nov 07, 2025 at 11:28:27AM +, Bertrand Drouvot wrote: > While there are existing rewrite tests, the stats behavior during rewrites > doesn't have a good coverage. This patch adds some tests to record some stats > after different rewrite scenarios. > > That way, we'll be able to test th

Re: IO in wrong state on riscv64

On Sun, Nov 9, 2025 at 8:26 AM Tom Lane wrote: > ... BTW, I wonder why you did not add pg_compiler_barrier_impl() > to our other use of __atomic_thread_fence: > > #if !defined(pg_memory_barrier_impl) > #if defined(HAVE_GCC__ATOMIC_INT32_CAS) > #define pg_memory_barrier_impl() >

Re: MSVC: Improve warning options set

Thomas Munro writes: > What we should do to make this clearer and avoid spurious problem > reports is error out unless you're on UCRT, but a patch for that got > stuck waiting for the Debian images used on CI to be upgraded to > Debian trixie, because that shipped the necessary newer > MinGW/heade

Re: MSVC: Improve warning options set

On Tue, Nov 4, 2025 at 7:56 AM Peter Eisentraut wrote: > On 31.10.25 14:31, Bryan Green wrote: > > The real question is MinGW. If we still support MinGW builds targeting > > the old MSVCRT, those need the environ declaration. If we require MinGW > > with UCRT, we don't. You'd need something like "

[PATCH] Implement condition variable-based WAL waiting for logical decoding

Hello contributors This patch implements a condition variable-based approach for WAL waiting in logical decoding, replacing the previous polling mechanism. The new system provides significant efficiency improvements by eliminating unnecessary CPU cycles during WAL waiting periods. Key changes: 1

Re: should we have a fast-path planning for OLTP starjoins?

[ Don't have time to read the v4 patch right now, but a couple of quick responses: ] Tomas Vondra writes: > On 9/23/25 21:46, Tom Lane wrote: >> I'd be slightly inclined to put the GUC test there, too: >> >> +if (enable_starjoin_join_search) >> +joinlist = starjoin_adjust_joins(r

[PATCH] libpq: Wrap out-of-memory error messages with libpq_gettext()

Hi, The recent patch for passwordFromFile() error handling highlighted that many other out-of-memory error messages in libpq still aren't wrapped with libpq_gettext(). Attached is a patch that systematically wraps the remaining bare "out of memory" strings across libpq with libpq_gettext() to ens

Re: should we have a fast-path planning for OLTP starjoins?

On 9/23/25 21:46, Tom Lane wrote: > [ sorry for ridiculously slow response to this ] > > Tomas Vondra writes: >> Here's a patch trying to do it more like this - by manipulating the >> lists describing the join problems, before it's passed the the actual >> join search algorithm (which is where th

Re: IO in wrong state on riscv64

... BTW, I wonder why you did not add pg_compiler_barrier_impl() to our other use of __atomic_thread_fence: #if !defined(pg_memory_barrier_impl) #if defined(HAVE_GCC__ATOMIC_INT32_CAS) #define pg_memory_barrier_impl() __atomic_thread_fence(__ATOMIC_SEQ_CST) #elif defined(__

Re: ago(interval) → timestamptz

On Sat, 2025-11-08 at 09:09 +0100, Andreas Karlsson wrote: > On 11/6/25 3:54 PM, Laurenz Albe wrote: > > On Thu, 2025-11-06 at 12:15 +0100, Florents Tselai wrote: > > > > I don't get what users would need ago(interval) -> timestamp. That > > > > function would > > > > not make any sense since ther

Re: pg_dump not dumping default_text_search_config WAI?

Philip Warner writes: > I just got bitten by dumping and restoring a database to a new cluster, > and the default_text_search_config was not copied for the database. > A check of the dump file shows no 'ALTER DATABASE' command. IIRC you'd need to use --create to prod pg_dump to produce a CREAT

Re: Use bsearch() instead of a manual binary search in syscache.c

Thomas Munro writes: > One factor is that libc bsearch() implementations might not all be > header-only and inlineable. I vaguely recall that being discussed in > some round of hacking on qsort() and qunique(). I'm quite certain that years ago we determined that bsearch() was slower than a manua

Re: MSVC: Improve warning options set

On 03.11.25 20:26, Andres Freund wrote: On 2025-11-03 19:56:16 +0100, Peter Eisentraut wrote: I don't know if we still support MSVCRT if using MSVC, or how long we still need to support it. (Or, for example, how to tell which variant CI or the buildfarm uses.) To my knowledge anything close t

Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement

On 08/11/2025 15:05, Manni Wood wrote: > Apologies for the noise. Just wanted to confirm that I did a fresh clone > of github.com/postgres/postgres on > my linux machine, applied both v9 patches to master, ran  > "configure", "make world", "make check-world"

pg_dump not dumping default_text_search_config WAI?

I just got bitten by dumping and restoring a database to a new cluster, and the default_text_search_config was not copied for the database. A check of the dump file shows no 'ALTER DATABASE' command. I used an 'ALTER DATABASE...' to set it correctly and then did a dump, and the config was not

Re: Optimize LISTEN/NOTIFY

On Sat, Nov 8, 2025, at 13:59, Joel Jacobson wrote: > On Fri, Nov 7, 2025, at 19:59, Joel Jacobson wrote: >> * The logic in SignalBackends has been reworked and simplified, >> thanks to the new isAdvancing and advancingPos fields. >> I now think it's finally easy to reason about why each branch

Re: DOCS: What SGML markup to use for user objects like tables, columns, etc?

On Tue, Nov 4, 2025 at 02:35:29PM +1100, Peter Smith wrote: > On Thu, Jul 24, 2025 at 2:18 AM Bruce Momjian wrote: > ... > > You are right that we are inconsistent. I think is the > > accepted way to reference table names, and for column > > names. If you can create a patch to make them consi

Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement

On Fri, Nov 7, 2025 at 10:46 PM Manni Wood wrote: > > > On Fri, Nov 7, 2025 at 10:19 PM Manni Wood > wrote: > >> >> >> On Fri, Nov 7, 2025 at 6:03 PM Jim Jones >> wrote: >> >>> >>> >>> On 08/11/2025 00:38, Manni Wood wrote: >>> > Alas, the build https://commitfest.postgresql.org/patch/6175/ >>>

Re: Use bsearch() instead of a manual binary search in syscache.c

On Sun, Nov 9, 2025 at 1:12 AM Antonin Houska wrote: > cca5507 wrote: > > I make a patch for the $subject, which make the code simpler, thoughts? > > I proposed something like that earlier [1] but did not get too far. The short > discussion might be useful for you though. One factor is that libc

Re: Optimize LISTEN/NOTIFY

On Fri, Nov 7, 2025, at 19:59, Joel Jacobson wrote: > * The logic in SignalBackends has been reworked and simplified, > thanks to the new isAdvancing and advancingPos fields. > I now think it's finally easy to reason about why each branch > in SignalBackends must be correct. I was wrong. I w

Re: Use bsearch() instead of a manual binary search in syscache.c

cca5507 wrote: > I make a patch for the $subject, which make the code simpler, thoughts? I proposed something like that earlier [1] but did not get too far. The short discussion might be useful for you though. [1] https://www.postgresql.org/message-id/36977.1720623613@antos -- Antonin Houska

Re: Add tab completion support for WAIT FOR command

Hi, Xuneng! On Fri, Nov 7, 2025 at 12:10 PM Xuneng Zhou wrote: > The WAIT FOR command was committed in 447aae1; this patch has been > updated to match its grammar. I made minor adjustments to the patch. I'm going to push it if no objections. -- Regards, Alexander Korotkov Supabase v3-000

Re: Support allocating memory for large strings

On 8/11/25 3:15, Maxim Zibitsker wrote: PostgreSQL's MaxAllocSize limit prevents storing individual variable-length character strings exceeding ~1GB, causing "invalid memory alloc request size" errors during INSERT operations on tables with large text columns. Example reproduction included in

Re: display hot standby state in psql prompt

Hi Andreas On 08/11/2025 09:57, Andreas Karlsson wrote: > I am not a fan at all of introducing running a query when calculating > the prompt. Imagine if there are network issues or otherwise and in > general I imagine that the prompt can send a query would be highly > surprising to most users. I

Re: [Patch] Windows relation extension failure at 2GB and 4GB

On Fri, Nov 07, 2025 at 12:32:21PM +0900, Michael Paquier wrote: > On Fri, Nov 07, 2025 at 03:56:07PM +1300, Thomas Munro wrote: >> (It's signed per POSIX and on Windows so I assume you meant to write 2GB >> here.) > > Yes, right.. So, please find attached a patch that adds a check for large fil

Re: display hot standby state in psql prompt

On 10/31/25 10:00 PM, Jim Jones wrote: Thoughts on this approach? I am not a fan at all of introducing running a query when calculating the prompt. Imagine if there are network issues or otherwise and in general I imagine that the prompt can send a query would be highly surprising to most us

Re: ago(interval) → timestamptz

On 11/6/25 3:54 PM, Laurenz Albe wrote: On Thu, 2025-11-06 at 12:15 +0100, Florents Tselai wrote: I don't get what users would need ago(interval) -> timestamp. That function would not make any sense since there is no equivalent to now() which returns timestamp, simply because a timestamp does