Re: Need clarification on compilation errors in PG 16.2

Hi Long, >In fact, whether the HAVE_MEMSET_S macro is defined determines whether the implementation >of the explicit_bzero() function calls memset_s() or memset(). This macro is undefined by default >in pg_config.h, so check to see if your build environment has a HAVE_MEMSET_S macro defined. Yes

why memoize is not used for correlated subquery

Hi I am playing with examples for P2D2, and I found few issues related to memoize 1. I use dataset https://pgsql.cz/files/obce.sql - it is data about czech population Dictionary - "obec" -> "village", "pocet_muzu" -> "number_of_men", "pocet_zen" -> "number_of_woman", "okres" -> "district", "naze

Re: why memoize is not used for correlated subquery

Pavel Stehule 于2024年5月28日周二 15:31写道： > Hi > > > My question is - does memoize support subqueries? And can be enhanced to > support this exercise without LATERAL and optimization fences? > > The commit messages in memoize may answer your question: "For now, the planner will only consider using

Re: why memoize is not used for correlated subquery

On Tue, 28 May 2024 at 19:31, Pavel Stehule wrote: > My question is - does memoize support subqueries? And can be enhanced to > support this exercise without LATERAL and optimization fences? It's only currently considered for parameterized nested loop joins, not for subplans. I wrote a bit abou

Re: why memoize is not used for correlated subquery

út 28. 5. 2024 v 9:48 odesílatel David Rowley napsal: > On Tue, 28 May 2024 at 19:31, Pavel Stehule > wrote: > > My question is - does memoize support subqueries? And can be enhanced to > support this exercise without LATERAL and optimization fences? > > It's only currently considered for parame

Re: Use pgBufferUsage for block reporting in analyze

Thanks for having a look. On Fri, May 10, 2024 at 12:40 PM Michael Paquier wrote: > This needs some runtime check to make sure that the calculations > are consistent before and after the fact (cannot do that now). > Yeah, testing this is also a bit painful as buffer usage of analyze is only disp

Re: Conflict Detection and Resolution

On Mon, May 27, 2024 at 11:19 AM shveta malik wrote: > > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra > wrote: > > > > On 5/23/24 08:36, shveta malik wrote: > > > Hello hackers, > > > > > > Please find the proposal for Conflict Detection and Resolution (CDR) > > > for Logical replication. > > >

ON ERROR in json_query and the like

Hi! I’ve noticed two “surprising” (to me) behaviors related to the “ON ERROR” clause of the new JSON query functions in 17beta1. 1. JSON parsing errors are not subject to ON ERROR Apparently, the functions expect JSONB so that a cast is implied when providing TEXT. However, the errors durin

Re: Parallel CREATE INDEX for GIN indexes

Hi Tomas, I have completed my first round of review, generally it looks good to me, more testing need to be done in the next days. Here are some tiny comments from my side, just FYI. 1. Comments about GinBuildState.bs_leader looks not good for me. /* * bs_leader is only p

Re: why memoize is not used for correlated subquery

> I imagined making this work by delaying the plan creation for > subqueries until the same time as create_plan() for the outer query. Do you mean sublinks rather than subqueries? if so, we can get another benefit I want very much. explain (costs off) select * from t1 where t1.a = 1

Re: ON ERROR in json_query and the like

út 28. 5. 2024 v 11:29 odesílatel Markus Winand napsal: > Hi! > > I’ve noticed two “surprising” (to me) behaviors related to > the “ON ERROR” clause of the new JSON query functions in 17beta1. > > 1. JSON parsing errors are not subject to ON ERROR >Apparently, the functions expect JSONB so th

Re:[PATCH]A minor improvement to the error-report in SimpleLruWriteAll()

Hi, Actually, I still wonder why only the error message of the last failure to close the file was recorded. For this unusual situation, it is acceptable to record all failure information without causing too much logging. Was it designed that way on purpose? At 2024-05-25 17:29:00, "Long Song"

Re: pgsql: Add more SQL/JSON constructor functions

On Monday, May 27, 2024, Alvaro Herrera wrote: > On 2024-May-27, Alvaro Herrera wrote: > > > > JSON_SERIALIZE() > > I just noticed this behavior, which looks like a bug to me: > > select json_serialize('{"a":1, "a":2}' returning varchar(5)); > json_serialize > > {"a": > > I thi

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 4:00 PM Joe Conway wrote: > > On 5/16/24 17:36, Jacob Champion wrote: > > On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote: > >> If no one, including the author (new or otherwise) is interested in > >> shepherding a particular patch, what chance does it have of ever gettin

Re: commitfest.postgresql.org is no longer fit for purpose

On Fri, May 17, 2024 at 9:59 AM Robert Haas wrote: > > On Fri, May 17, 2024 at 11:05 AM Tom Lane wrote: > > > We already have gone back to that model. We just haven't admitted it > > > yet. And we're never going to get out of it until we find a way to get > > > the contents of the CommitFest appl

Re: Add last_commit_lsn to pg_stat_database

On Thu, Mar 7, 2024 at 10:30 AM Heikki Linnakangas wrote: > > > I've previously noted in "Add last commit LSN to > > pg_last_committed_xact()" [1] that it's not possible to monitor how > > many bytes of WAL behind a logical replication slot is (computing such > > is obviously trivial for physical

small fix for llvm build

I'm getting build failures when building with meson and llvm enabled, like this: [1/112] Generating src/backend/jit/llvm/llvmjit_types.bc with a custom command FAILED: src/backend/jit/llvm/llvmjit_types.bc /usr/local/bin/ccache /usr/local/Cellar/llvm/18.1.6/bin/clang -c -o src/backend/jit/llv

Re: Schema variables - new implementation for Postgres 15

Hi so 25. 5. 2024 v 3:29 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > we can introduce special safe mode started by > > set enable_direct_variable_read to off; > > and allowing access to variables only by usage dedicated function > > (supported by parser) named like variable or pg_va

Re: Add last_commit_lsn to pg_stat_database

On Mon, Feb 19, 2024 at 3:56 PM Michael Paquier wrote: > > On Mon, Feb 19, 2024 at 10:26:43AM +0100, Tomas Vondra wrote: > > On 2/19/24 07:57, Michael Paquier wrote: > > > On Sun, Feb 18, 2024 at 02:28:06AM +0100, Tomas Vondra wrote: > >>> 1) Do we really need to modify RecordTransactionCommitPrep

Re: errors building on windows using meson

Hi I was facing the same error when using active state perl for compiling postgres with meson on windows. I used active state perl because it was working fine for pg compilations until pg-16. Using choco strawberry perl solved my problem. Thanks Imran Zaheer On Wed, 29 May 2024 at 00:22, Dave

Avoid an odd undefined behavior with memcmp (src/bin/pg_rewind/pg_rewind.c)

Hi. The function *perform_rewind* has an odd undefined behavior. The function memcmp/ , compares bytes to bytes. IMO, I think that pg_rewind can have a security issue, if two files are exactly the same, they are considered different. Because use of

Windows: openssl & gssapi dislike each other

I recently noticed that at least with PostgreSQL 16, it is not possible to build using MSVC if both OpenSSL and gssapi (MIT Kerberos) are enabled. Both work if the other isn't included though.. I briefly tried to test with PG17 to see if it has the same issue, but it seems like gssapi has the same

Re: Need clarification on compilation errors in PG 16.2

Pradeep Kumar writes: > Yes it was defined in "pg_config.h" > /* Define to 1 if you have the `memset_s' function. */ > #define HAVE_MEMSET_S 1 That's correct for recent versions of macOS. I see you are building against a recent SDK: /Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/in

Re: Need clarification on compilation errors in PG 16.2

> On 28 May 2024, at 22:51, Tom Lane wrote: > > Pradeep Kumar writes: >> Yes it was defined in "pg_config.h" >> /* Define to 1 if you have the `memset_s' function. */ >> #define HAVE_MEMSET_S 1 > > That's correct for recent versions of macOS. I see you are > building against a recent SDK: > >

Re: meson vs windows perl

Hi, On 2024-04-05 16:12:12 -0400, Andrew Dunstan wrote: > OK, this has been fixed and checked. The attached is what I propose. The perl command is pretty hard to read. What about using python's shlex module instead? Rough draft attached. Still not very pretty, but seems easier to read? It'd be

Re: In-placre persistance change of a relation

On Fri, 24 May 2024 at 00:09, Kyotaro Horiguchi wrote: > Along with rebasing, I changed the interface of XLogFsyncFile() to > return a boolean instead of an error message. Two notes after looking at this quickly during the advanced patch feedback session: 1. I would maybe split 0003 into two sep

Re: DROP OWNED BY fails to clean out pg_init_privs grants

Hi Daniel, pg_upgrade is just one important user of pg_dump which is the one that generates REVOKE for a non-existent role. We should definitely also fix pg_dump, likely just checking that the role exists when generating REVOKE commands (may be a good practice for other cases too so instead of ca

Re: pgsql: Add more SQL/JSON constructor functions

Hi Alvaro, On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera wrote: > > On 2024-May-27, Alvaro Herrera wrote: > > > > JSON_SERIALIZE() > > I just noticed this behavior, which looks like a bug to me: > > select json_serialize('{"a":1, "a":2}' returning varchar(5)); > json_serialize > ───

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

On Mon, Feb 19, 2024 at 5:17 AM Ashutosh Bapat wrote: > On Mon, Feb 19, 2024 at 4:35 AM Tomas Vondra > wrote: > > > > Hi, > > > > After taking a look at the patch optimizing SpecialJoinInfo allocations, > > I decided to take a quick look at this one too. I don't have any > > specific comments on

Re: Improving the latch handling between logical replication launcher and worker processes.

On Thu, Apr 25, 2024 at 6:59 PM vignesh C wrote: > ... > a) Introduce a new latch to handle worker attach and exit. IIUC there is normally only the “shared” latch or a “process local” latch. i.e. AFAICT is is quite uncommon to invent a new latches like option a is proposing. I did not see any exa

Re: Need clarification on compilation errors in PG 16.2

Hello Tom, >That's correct for recent versions of macOS. I see you are >building against a recent SDK: > >/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include/string.h > >but I wonder if maybe the actual OS version is back-rev? Currently Im using "MacOSX14.4.sdk" , path is "/Libra

Re: Need clarification on compilation errors in PG 16.2

Hi, I found out that for using memset() library is not referred from "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/string.h" , it referred from "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include/secure/_string.h", in that file didn't defined the memset_s()

Re: meson: Specify -Wformat as a common warning flag for extensions

On 07.04.24 18:01, Sutou Kouhei wrote: +# We don't have "warning_level == 3" and "warning_level == +# 'everything'" here because we don't use these warning levels. +if warning_level == '1' + common_builtin_flags += ['-Wall'] +elif warning_level == '2' + common_builtin_flags += ['-Wall', '-Wextr

meson "experimental"?

In installation.sgml it says """ Alternatively, PostgreSQL can be built using Meson. This is currently experimental. """ Do we want to alter this statement for PG17, considering that this is now the only way to build for Windows using MSVC? (A joke response is that the Windows port itself

Re: meson: Specify -Wformat as a common warning flag for extensions

Hi, In <4707d4ed-f268-43c0-b4dd-cdbc7520f...@eisentraut.org> "Re: meson: Specify -Wformat as a common warning flag for extensions" on Tue, 28 May 2024 23:31:05 -0700, Peter Eisentraut wrote: > On 07.04.24 18:01, Sutou Kouhei wrote: >> +# We don't have "warning_level == 3" and "warning_level