Re: Support for runtime parameters in injection points, for AIO tests

On Fri, May 09, 2025 at 10:48:45AM +0900, Michael Paquier wrote: > Thanks for the input. Will proceed if there are no objections, then. By the way, Greg, v2-0003 in the patch set you have posted was incorrect; it missed most of the wanted changes to get rid of the workarounds in the AIO code. Co

Re: queryId constant squashing does not support prepared statements

On Fri, May 9, 2025 at 1:35 PM Michael Paquier wrote: > > On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote: > > Why not a location and a length, it should be more natural, it > > seems we use this convention in some existing nodes, like > > RawStmt, InsertStmt etc. > > These are new co

Re: pgsql: Make cancel request keys longer

On 09/05/2025 01:28, Jacob Champion wrote: On Thu, May 8, 2025 at 12:11 PM Heikki Linnakangas wrote: Polished this up a tiny bit, and committed. Thanks! I think the uint8->int change for cancel_key_len is more than just cosmetic; it most likely fixes a bug where a key size of 256 wrapped arou

Re: Assert failure in base_yyparse

On Mon, Apr 14, 2025 at 5:45 PM Richard Guo wrote: > It seems what happens is that internally in gram.y (~line 14274), the > DefElem for the not-null option is assigned the name "is_not_null". > As a result, this allows users to explicitly use "is_not_null" as the > option name. However, the valu

Re: queryId constant squashing does not support prepared statements

On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote: > Why not a location and a length, it should be more natural, it > seems we use this convention in some existing nodes, like > RawStmt, InsertStmt etc. These are new concepts as of Postgres 18 (aka only on HEAD), chosen mainly to match

Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData

On Tue, Feb 18, 2025 at 04:57:47PM -0800, Noah Misch wrote: > As I wrote in [1], "By the time we reach consistency, every file in > pg_twophase will be applicable (not committed or aborted)." If we find > otherwise, the user didn't follow the backup protocol (or there's another > bug). Hence, long

Re: queryId constant squashing does not support prepared statements

Hi Dmitry, On Fri, May 9, 2025 at 3:36 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > > Ah, I see what you mean. I think the idea is fine, it will simplify >

Re: PG 18 release notes draft committed

On Fri, May 9, 2025 at 11:47 AM Richard Guo wrote: > On Fri, May 9, 2025 at 12:18 AM Bruce Momjian wrote: > > On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote: > > > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote: > > > > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote

Re: PG 18 release notes draft committed

On Fri, May 9, 2025 at 12:18 AM Bruce Momjian wrote: > On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote: > > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote: > > > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote: > > > > I'm wondering if we should consider mentioning tha

Re: AIO v2.5

On Thu, May 08, 2025 at 09:06:18PM -0400, Andres Freund wrote: > On 2025-05-02 20:05:11 -0700, Noah Misch wrote: > > On Wed, Apr 30, 2025 at 04:00:35PM -0400, Andres Freund wrote: > We do need to hold interrupts in a few other places, I think - with some debug > infrastructure (things like calling

RE: Fix slot synchronization with two_phase decoding enabled

On Thu, May 8, 2025 at 6:04 PM Zhijie Hou (Fujitsu) wrote: > > On Tue, May 6, 2025 at 7:22 PM Zhijie Hou (Fujitsu) wrote: > > > > > On Mon, May 5, 2025 at 6:59 PM Amit Kapila wrote: > > > > > > On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada > > > > > wrote: > > > > > > > > While I cannot be enti

Why our Valgrind reports suck

A nearby thread [1] reminded me to wonder why we seem to have so many false-positive leaks reported by Valgrind these days. For example, at exit of a backend that's executed a couple of trivial queries, I see ==00:00:00:25.515 260013== LEAK SUMMARY: ==00:00:00:25.515 260013==definitely lost: 3

Re: Support for runtime parameters in injection points, for AIO tests

On Thu, May 08, 2025 at 09:18:15PM -0400, Andres Freund wrote: > I'm ok with it happening now or only in master after branching off. Either > seems justifiable to me. I really don't have much of an opinion about it - it > seems you do, so we should probably go with that. Thanks for the input. Wi

Re: Support for runtime parameters in injection points, for AIO tests

Hi, On 2025-05-09 08:19:39 +0900, Michael Paquier wrote: > On Thu, May 08, 2025 at 06:16:46PM +, Greg Burd wrote: > > IMO seems like a good idea, happy to help further "cleanup the AIO > > code" with some direction as to what needs to be done. > > Thanks for posting a rebase. Yes, I would li

Re: AIO v2.5

Hi, On 2025-04-23 00:38:01 +0200, Tomas Vondra wrote: > There's an open item related to this commit (247ce06b883d), based on: Oops, forgot to reply. > For now the default io_method is changed to "worker". We should re- > evaluate that around beta1, we might want to be careful and set th

Re: AIO v2.5

Hi, On 2025-05-02 20:05:11 -0700, Noah Misch wrote: > On Wed, Apr 30, 2025 at 04:00:35PM -0400, Andres Freund wrote: > > pgaio_io_wait_for_free() does what it says on the tin. For that, after a > > bunch > > of other things, finds the oldest in-flight IO and waits for it. > > > > PgA

Re: disabled SSL log_like tests

Daniel Gustafsson writes: > Maybe the ssl_library function should return a hash with backend => 'OpenSSL' > and library => ? I don't love doing it exactly like that: seems like it adds notational complexity for little gain. Also, it forces ssl_library to expend work detecting things the current

Re: queryId constant squashing does not support prepared statements

On Thu, May 08, 2025 at 03:50:32PM -0500, Sami Imseih wrote: > On Thu, May 8, 2025 at 2:36 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: >> To clarify, I had in mind something like in the attached patch. The >> idea is to make start/end location capturing relatively independent from >> the consta

Re: Support for runtime parameters in injection points, for AIO tests

On Thu, May 08, 2025 at 06:16:46PM +, Greg Burd wrote: > IMO seems like a good idea, happy to help further "cleanup the AIO > code" with some direction as to what needs to be done. Thanks for posting a rebase. Yes, I would like to clean up that on HEAD, but it also seems like Andres would pre

Re: pgsql: Make cancel request keys longer

On Thu, May 8, 2025 at 12:11 PM Heikki Linnakangas wrote: > Polished this up a tiny bit, and committed. Thanks! I think the uint8->int change for cancel_key_len is more than just cosmetic; it most likely fixes a bug where a key size of 256 wrapped around to 0. I'll double-check that this fixes th

Re: [PATCH] Fix missing comma in Requires.private with a Make macro

On Thu, May 8, 2025 at 1:07 PM Tom Lane wrote: > I'm not aware of one, but it seems like a reasonable idea ... I've created a skeleton at https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions, based on our dev documentation and some recent threads. Still plenty to fill in, if anyone knows

Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch

Hi, Thanks for the work on this, but I am -1 on this idea. It sounds like the type of workload that could become problematic here is one in which there is a massive delete of data which leaves many truncate-able pages at the end of the table and vacuum kicks in while there is heavy concurrent read

RE: Fix slot synchronization with two_phase decoding enabled

On Tue, May 6, 2025 at 7:22 PM Zhijie Hou (Fujitsu) wrote: > > On Mon, May 5, 2025 at 6:59 PM Amit Kapila wrote: > > > > On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada > > > wrote: > > > > > > While I cannot be entirely certain of my analysis, I believe the > > > root cause might be related to

Re: Valgrind - showing memory leaks

On Thu, May 8, 2025 at 6:17 PM Álvaro Herrera wrote: > On 2025-05-08, Yasir wrote: > > > I believe that the valgrind should not report any memory leaks in such > > simple/common commands. What am I doing wrong here? > > Hmm, that function was modified relatively recently so I think you found a >

Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch

Thank you for engaging into the conversation and sharing your thoughts Sami and Robert. On Thu, May 8, 2025 at 2:57 PM Sami Imseih wrote: > > actually determine you are in this situation, or how bad the situation > > was, in order to know that setting truncate off would help? To that > > That's

Re: Valgrind - showing memory leaks

On 2025-May-08, Tom Lane wrote: > Alvaro seems to think CheckNNConstraintFetch is worth taking > a second look at, and maybe he's right, but the amount of > storage involved there seems unexciting too. Yeah, I think the new issue here is that we're calling that function at all; previously we woul

Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch

On Thu, May 8, 2025 at 12:10 PM Sami Imseih wrote: > I think it's better to simply disable the truncate work and perform it > at a later time > than introduce some new limit to how many times the truncation can be > suspended. > In the type of workload you are referring to, it is likely that the

Re: queryId constant squashing does not support prepared statements

On Thu, May 8, 2025 at 2:36 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > > Ah, I see what you mean. I think the idea is fine, it will simplify > > > certain

Re: disabled SSL log_like tests

> On 8 May 2025, at 22:24, Tom Lane wrote: > > Daniel Gustafsson writes: >> On 8 May 2025, at 15:49, Tom Lane wrote: >>> I was feeling itchy about having two copies of code that looks none >>> too set-in-stone. Maybe we should just do that. Any preferences >>> on the API? > >> There is alrea

Re: Valgrind - showing memory leaks

=?utf-8?Q?=C3=81lvaro?= Herrera writes: > If the table doesn't have check constraints, we end up doing > MemoryContextAllocZero() with size 0 in CacheMemoryContext, which isn't > great (IIUC we innecessarily allocate a chunk of size 8 in this case). > I think we should make the allocation conditio

Re: disabled SSL log_like tests

Daniel Gustafsson writes: > On 8 May 2025, at 15:49, Tom Lane wrote: >> I was feeling itchy about having two copies of code that looks none >> too set-in-stone. Maybe we should just do that. Any preferences >> on the API? > There is already SSL::Server::ssl_library() which returns the underlyi

Re: [PATCH] Fix missing comma in Requires.private with a Make macro

Jacob Champion writes: > Is there maybe a wiki page where we gather the reasoning for our > pinned minimum versions? None of my searches turned anything up, but > it might help accelerate some of these conversations. I'm not aware of one, but it seems like a reasonable idea ...

Re: Fix PQport to never return NULL if the connection is valid

I looked a bit more into the meaning of the port="" setting. The docs for the port parameter / PGPORT env var say: An empty string, or an empty item in a comma-separated list, specifies the default port number

Re: Valgrind - showing memory leaks

On Thu, May 8, 2025 at 7:27 PM Tom Lane wrote: > Yasir writes: > > I believe that the valgrind should not report any memory leaks in such > > simple/common commands. What am I doing wrong here? > > I think you are vastly overestimating both the intelligence of > valgrind, and our level of concer

Re: queryId constant squashing does not support prepared statements

> On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > Ah, I see what you mean. I think the idea is fine, it will simplify > > certain things as well as address the issue. But I'm afraid adding > > start/end location to

Re: pgsql: Make cancel request keys longer

On 09/04/2025 13:46, Heikki Linnakangas wrote: On 09/04/2025 13:28, Heikki Linnakangas wrote: On 09/04/2025 12:39, Peter Eisentraut wrote: On 09.04.25 10:53, Heikki Linnakangas wrote: On 08/04/2025 22:41, Heikki Linnakangas wrote: On 08/04/2025 20:06, Peter Eisentraut wrote: While I was looki

Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch

> actually determine you are in this situation, or how bad the situation > was, in order to know that setting truncate off would help? To that Adding counters for this area is not a bad idea in general, as this hits customers particularly hard on hot standbys when the truncate does actually occur

Re: Issue attaching a table to a partitioned table with an auto-referenced foreign key

On 2025-May-08, Matthew Gabeler-Lee wrote: > My earlier test case, and an adjusted version of it that is closer to > my production application (notably adding ON DELETE CASCADE to the > FK), now passes with 15.13. Thank you, that's a relief to know. -- Álvaro Herrera PostgreSQL Develope

Re: Fix PQport to never return NULL if the connection is valid

On Thu, 8 May 2025 at 18:58, Daniele Varrazzo wrote: > I have prepared a patch, which is attached, to fix the issue. However > the patch returns the default port in case of no info in > 'conn->connhost'. Ah, of course this is wrong if the PGPORT env var is set and I assume thanks to the pg_servi

Re: Issue attaching a table to a partitioned table with an auto-referenced foreign key

On Sat, May 3, 2025 at 9:09 AM Alvaro Herrera wrote: > Y'all are still on time to test this a bit more before next week's > releases ... if I have made things even worse I can still revert the > patch. With luck, that won't be necessary. I was not able to get to testing this before the release,

Re: disabled SSL log_like tests

> On 8 May 2025, at 15:49, Tom Lane wrote: > > Daniel Gustafsson writes: >> On 7 May 2025, at 23:54, Tom Lane wrote: >>> +# Determine whether this build uses OpenSSL or LibreSSL. As a heuristic, >>> the >>> +# HAVE_SSL_CTX_SET_CERT_CB macro isn't defined for LibreSSL. >>> +my $libressl = not c

Fix PQport to never return NULL if the connection is valid

The documentation of PQport says that the function will never return NULL, unless the connection is null: https://www.postgresql.org/docs/17/libpq-status.html#LIBPQ-PQPORT However this is not the case: it seems to return null when the port specified is an empty string: $ PSYCOPG_IMPL=python p

Re: [PATCH] oauth: Prevent stack overflow by limiting JSON parse depth

On Thu, May 8, 2025 at 5:22 AM Aleksander Alekseev wrote: > Thanks for the patch. It looks good to me. It's well documented and > covered with tests. I can confirm that the tests pass. Also they fail > if I decrease the $nesting_limit value to 15. Thanks for the review! --Jacob

Re: [PATCH] Fix missing comma in Requires.private with a Make macro

On Wed, May 7, 2025 at 3:39 PM Álvaro Herrera wrote: > Well, Jacob did say that he tested it with 3.81, so this patch should be > okay. Upping the minimum version can be discussed elsewhere ... or > maybe never, if we end up replacing it wholesale with Meson/ninja. To be fair, I did invite debat

Re: regdatabase

On Thu, May 08, 2025 at 10:38:04PM +0900, Ian Lawrence Barwick wrote: > Revised patch attached which adds coverage of that and also for the > "constant of the type reg(role|database) cannot be used here" error. LGTM. I've marked it as ready-for-committer [0] and will plan on committing it as soon

Re: PG 18 release notes draft committed

On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote: > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote: > > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote: > > > I'm wondering if we should consider mentioning that several > > > long-standing issues related to grouping sets

Re: PG 18 release notes draft committed

On Thu, May 8, 2025 at 03:45:00PM +0800, jian he wrote: > On Fri, May 2, 2025 at 10:44 AM Bruce Momjian wrote: > > > > release-18: 209 > > > > I will continue improving it until beta 1, and until the final release. > > I will probably add markup in 1-3 weeks. Let the feedback begin. ;

Re: Valgrind - showing memory leaks

Yasir writes: > I believe that the valgrind should not report any memory leaks in such > simple/common commands. What am I doing wrong here? I think you are vastly overestimating both the intelligence of valgrind, and our level of concern about minor one-time leaks. Most of these are probably not

Re: Improve docs for n_distinct_inherited

On Wed, May 7, 2025 at 11:41 PM David Rowley wrote: > On Thu, 8 May 2025 at 15:23, David G. Johnston > wrote: > > Not liking the proposal, not sure it is even correct. Somehow "children > of inheritance parent tables" are omitted. > > I don't see the quoted text anywhere in this area, so I'm no

Re: disabled SSL log_like tests

Daniel Gustafsson writes: > On 7 May 2025, at 23:54, Tom Lane wrote: >> +# Determine whether this build uses OpenSSL or LibreSSL. As a heuristic, the >> +# HAVE_SSL_CTX_SET_CERT_CB macro isn't defined for LibreSSL. >> +my $libressl = not check_pg_config("#define HAVE_SSL_CTX_SET_CERT_CB 1"); > L

Re: Call for Posters: PGConf.dev 2025

> On 15 Apr 2025, at 11:47, Andrey Borodin wrote: > > I’m going to print their posters on May 8th before my flight to Canada. Following posters were printed, packaged and prepared to accompany me on a flight to Montreal. 1. Logging Plan of the Running Query (Atsushi Torikoshi) 2. Data corru

Re: RFC: Allow EXPLAIN to Output Page Fault Information

On 2025-04-11 22:18, torikoshia wrote: On 2025-03-25 10:27, torikoshia wrote: On 2025-03-22 20:23, Jelte Fennema-Nio wrote: On Wed, 19 Mar 2025 at 14:15, torikoshia wrote: BTW based on your discussion, I thought this patch could not be merged anytime soon. Does that align with your understa

Re: regdatabase

2025年5月8日(木) 12:41 Nathan Bossart : > > On Wed, May 07, 2025 at 10:29:43AM -0400, Greg Sabino Mullane wrote: > > On Wed, May 7, 2025 at 4:55 AM Ian Lawrence Barwick > > wrote: > >> Version which applies/builds against current HEAD attached. I haven't yet > >> had a chance to look at the code beyon

Re: Valgrind - showing memory leaks

On 2025-05-08, Yasir wrote: > I believe that the valgrind should not report any memory leaks in such > simple/common commands. What am I doing wrong here? Hmm, that function was modified relatively recently so I think you found a genuine bug, which is probably mine. I'll have a look ... -- Ál

Re: Improve tab completion for COPY

Thanks for your comments! On 2025-05-08 08:53, Yugo Nagata wrote: On Wed, 7 May 2025 14:36:35 -0700 Masahiko Sawada wrote: On Wed, May 7, 2025 at 6:23 AM Yugo Nagata wrote: > > On Wed, 7 May 2025 15:39:26 +0900 > torikoshia wrote: > > > Hi, > > > > I noticed that REJECT_LIMIT, an option av

Re: [PATCH] Fix tags in func.sgml

Thanks to all the hackers for your quick response. 2025年5月8日(木) 15:44 Daniel Gustafsson : > > > On 8 May 2025, at 08:36, Noboru Saito wrote: > > > > Hi, > > > > Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a > > single tag, which was incorrect. > > This patch separates them int

Re: [PATCH] oauth: Prevent stack overflow by limiting JSON parse depth

Hi Jacob, > I forgot to put a recursion limit in the new OAuth parsers; the > server-side depth checks don't apply to the client, and it's not using > the incremental parser to move the burden from the stack to the heap. > Luckily, we track the nesting level already, so a fix (attached) can > be p

Re: Valgrind - showing memory leaks?

Hi Yasir > I ran a postgres server with valgrind looking for memory leaks at a > particular extension, but I am experiencing something strange. Here are the > steps: > [...] > 5. Question: > > I believe that the valgrind should not report any memory leaks in such > simple/commo

Re: disabled SSL log_like tests

> On 7 May 2025, at 23:54, Tom Lane wrote: > > Daniel Gustafsson writes: >> I haven't looked at the test in question yet, but we do skip some SSL tests >> if >> running against libressl already so I assume this will be able to follow the >> same pattern. > > Ah, thanks for the tip. I propose

Re: PG 18 release notes draft committed

On Thu, May 8, 2025 at 5:41 AM Bruce Momjian wrote: > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote: > > I'm wondering if we should consider mentioning that several > > long-standing issues related to grouping sets have been fixed starting > > from PostgreSQL v18. I understand that

Re: Remove unnecessary "lmgr.h" in stat_utils.c

On 2025-May-08, Michael Paquier wrote: > Seems worth doing to simplify the code in the long-run, even if these > require a case-by-case manual lookup. Yeah, I don't think we can take a patch that simply removes everything that this report mentions, because some of the includes (especially the sys

Re: Options to control remote transactions’ access/deferrable modes in postgres_fdw

On Sun, May 4, 2025 at 9:30 PM Etsuro Fujita wrote: > As read-only > subtransactions can’t change to read-write, and a read-only > main-transaction can’t change to read-write after first snapshot, > either (note: begin_remote_xact is called after it), all we need to do > is track the nesting level

Re: Remove unnecessary "lmgr.h" in stat_utils.c

On Wed, May 07, 2025 at 05:56:55PM +, Bertrand Drouvot wrote: > FWIW, please find attached a subset of the initial report that focus on > the "is not used directly" warnings. Seems worth doing to simplify the code in the long-run, even if these require a case-by-case manual lookup. Did you c

Re: PG 18 release notes draft committed

On Fri, May 2, 2025 at 10:44 AM Bruce Momjian wrote: > > release-18: 209 > > I will continue improving it until beta 1, and until the final release. > I will probably add markup in 1-3 weeks. Let the feedback begin. ;-) > > You can see the most current HTML-built version here: > >

Re: [PATCH] Fix tags in func.sgml

On Thu, May 08, 2025 at 03:36:53PM +0900, Noboru Saito wrote: > Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a > single tag, which was incorrect. > This patch separates them into two distinct tags for better > semantic correctness. Indeed, good catch. It looks like I've fat-fi

Re: [PATCH] Fix tags in func.sgml

>> On 8 May 2025, at 08:36, Noboru Saito wrote: >> >> Hi, >> >> Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a >> single tag, which was incorrect. >> This patch separates them into two distinct tags for better >> semantic correctness. > > Thanks for the patch, it looks corre