Re: IPC/MultixactCreation on the Standby server

> On 29 Jul 2025, at 23:15, Andrey Borodin wrote: > > I do not understand it yet. OK, I figured it out. SimpleLruDoesPhysicalPageExist() was reading a physical file and could race with real extension by ExtendMultiXactOffset(). So I used ExtendMultiXactOffset(actual + 1). I hope this does not

Re: proposal: plpgsql, new check for extra_errors - strict_expr_check

Hi st 30. 7. 2025 v 0:17 odesílatel Kirk Wolak napsal: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation:tested, passe

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

On Wed, Jul 30, 2025 at 9:07 PM Japin Li wrote: > ... > 2. > +Internal Relation Types: > +- -1: TID relation (maps CRID to original TID) > +- -2: NULL vector (bit array for NULL values) > +- -3: Delete vector (bit array for deleted records) > +- -5: TID-CRID mapping table > +- -9: Data WOS (b

Re: Pathify RHS unique-ification for semijoin planning

On Thu, Jul 31, 2025 at 10:33 AM Alexandra Wang wrote: > Thanks for the patch! I applied your patch and played around with it. Thanks for trying out this patch. > I have a question about the following test case you added in > subselect.sql: > I was under the impression that we wanted Unique on

Re: track generic and custom plans in pg_stat_statements

On Wed, Jul 30, 2025 at 02:05:09PM -0500, Sami Imseih wrote: > > > The term "NOT_SET" makes me itch a little bit, even if there is an > > > existing parallel with OverridingKind. Perhaps your proposal is OK, > > > still how about "UNKNOWN" instead to use as term for the default? > > +1 to "UNKNOWN

Re: Assertion failure in pgbench

> Hi, Tatsuo. > Do you understand why there is an assertion error in the immediate shutdown > case? No. I was not able to reproduce the case so far. Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp

Re: 024_add_drop_pub.pl might fail due to deadlock

On Wed, Jul 30, 2025 at 10:33 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Ajin, > > > Attaching the updated patches with the changes you requested. I've > > also added the unchanged patches for PG_18 and HEAD (PG_18_HEAD-v6*), > > so that everything is together in one mail. > > Thanks for update, b

Re: Assertion failure in pgbench

On Thu, Jul 31, 2025 at 9:03 AM Tatsuo Ishii wrote: > >> Hi, > >> > >> I encountered the following assertion failure in pgbench on the current > master: > >> > >> Assertion failed: (res == ((void*)0)), function discardUntilSync, > >> file pgbench.c, line 3515. > >> Abort trap: 6 > >> > >>

Re: Assertion failure in pgbench

>> Hi, >> >> I encountered the following assertion failure in pgbench on the current >> master: >> >> Assertion failed: (res == ((void*)0)), function discardUntilSync, >> file pgbench.c, line 3515. >> Abort trap: 6 >> >> >> This can be reliably reproduced with the following steps: >>

Re: Assertion failure in pgbench

> Hi, > > I encountered the following assertion failure in pgbench on the current > master: > > Assertion failed: (res == ((void*)0)), function discardUntilSync, > file pgbench.c, line 3515. > Abort trap: 6 > > > This can be reliably reproduced with the following steps: > > --

Re: Pathify RHS unique-ification for semijoin planning

Hi Richard, Thanks for the patch! I applied your patch and played around with it. I have a question about the following test case you added in subselect.sql: +-- Ensure that we can unique-ify expressions more complex than plain Vars +explain (verbose, costs off) +select * from semijoin_unique_tb

Re: Enhance pg_createsubscriber to create required standby.

On Wed, Jun 04, 2025 at 03:26:24PM +0530, Amit Kapila wrote: > On Wed, Jun 4, 2025 at 2:39 PM Peter Eisentraut wrote: >> It's not clear to me how this change now would substantially improve the >> user experience. The number of characters you type is approximately the >> same. You still need to

Re: track generic and custom plans in pg_stat_statements

On Wed, Jul 30, 2025 at 03:09:08PM -0500, Sami Imseih wrote: >> In practice, with this knowledge, we can access the CachedPlanSource of >> the corresponding PREPARED statement via an extension and override the >> decision made in 'auto' mode. Unfortunately, we cannot obtain a pointer >> to plan cac

Re: Support getrandom() for pg_strong_random() source

On Wed, Jul 30, 2025 at 02:03:53PM -0700, Jacob Champion wrote: > On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut > wrote: > > I imagine a "get entropy" operation could be very slow or even blocking, > > whereas a random number generator might just have to do some arithmetic > > starting from t

Re: Support getrandom() for pg_strong_random() source

On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut wrote: > I imagine a "get entropy" operation could be very slow or even blocking, > whereas a random number generator might just have to do some arithmetic > starting from the previous seed state. Agreed -- it could absolutely be slower, but if it

Re: track generic and custom plans in pg_stat_statements

> So, analysing > pg_s_s data, it would be beneficial to determine if a generic plan is > effective or not. Yes, this is the point of adding these statistics to pg_s_s. > In practice, with this knowledge, we can access the CachedPlanSource of > the corresponding PREPARED statement via an extensio

Re: pg_dump --with-* options

On 2025-Jul-30, Jeff Davis wrote: > On Wed, 2025-07-30 at 10:23 +0200, Álvaro Herrera wrote: > > Maybe we should invent a new > > switch, something like > >   --include=[schema,data,statistics] > > with which users can give one or more comma-separated types to be > > included in the dump.  > > R

Re: Support getrandom() for pg_strong_random() source

On 30.07.25 18:13, Jacob Champion wrote: On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut wrote: The POSIX description of getentropy() says: "The intended use of this function is to create a seed for other pseudo-random number generators." So using getentropy() for generating the random number

Re: track generic and custom plans in pg_stat_statements

On 7/30/25 21:05, Sami Imseih wrote: The term "NOT_SET" makes me itch a little bit, even if there is an existing parallel with OverridingKind. Perhaps your proposal is OK, still how about "UNKNOWN" instead to use as term for the default? +1 to "UNKNOWN". We currently use both UNKNOWN and NOT_

Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

> > > I didn't implement the [ FORMAT ] part for now. > please check the attached regress test and tests expected result. > Question about this: +/* + * Push steps to evaluate a SafeTypeCastExpr and its various subsidiary expressions. + * We already handle CoerceViaIO, CoerceToDomain, and ArrayC

Re: track generic and custom plans in pg_stat_statements

> > The term "NOT_SET" makes me itch a little bit, even if there is an > > existing parallel with OverridingKind. Perhaps your proposal is OK, > > still how about "UNKNOWN" instead to use as term for the default? > +1 to "UNKNOWN". We currently use both UNKNOWN and NOT_SET in different places. Ho

Re: Improve prep_buildtree

On 30.07.25 12:58, Nazir Bilal Yavuz wrote: Hi, On Wed, 30 Jul 2025 at 12:32, Peter Eisentraut wrote: On 30.07.25 10:28, Nazir Bilal Yavuz wrote: On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote: To fix this, I first tried to devise a way to detect whether a given directory is a build

Re: Non-text mode for pg_dumpall

On 2025-07-29 Tu 4:09 PM, Andrew Dunstan wrote: On 2025-07-28 Mo 8:04 AM, Andrew Dunstan wrote: On 2025-07-27 Su 7:56 PM, Noah Misch wrote: On Fri, Jul 25, 2025 at 04:59:29PM -0400, Tom Lane wrote: Andrew Dunstan writes: Before we throw the baby out with the bathwater, how about this sug

Re: support create index on virtual generated column.

On Tue, Jul 22, 2025 at 4:54 PM Tom Lane wrote: > Corey Huinker writes: > > I'm interested in this feature, specifically whether the optimizer uses > the > > index in situations where the expression is used rather than the virtual > > column name. > > Hmm, I kinda think we should not do this. T

Re: vacuumdb changes for stats import/export

Committed. -- nathan

Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

On Wed, Jul 30, 2025 at 12:22 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Sawada-san, > > While reading more, I found a race condition. Thank you for reviewing the patch! > In this case the effective_wal_level > can be logical even when there is no logical slot. > UpdateLogicalDecodingStatusEndOf

Re: vacuumdb changes for stats import/export

On Wed, 2025-07-30 at 12:21 -0500, Nathan Bossart wrote: > Here is what I have staged for commit. That's more clear to me. I also like that it shows that the options work well together, because that was not obvious before. Regards, Jeff Davis

Re: restore_command return code behaviour

On Wednesday, July 30, 2025, Jacob Champion wrote: > On Mon, Jul 28, 2025 at 3:38 PM David G. Johnston > wrote: > > On Monday, July 28, 2025, Jacob Champion com> wrote: > >> RestoreArchivedFile() has a special case for SIGTERM, though? > > > > I don’t see anything calling out sigterm by name. >

Re: vacuumdb changes for stats import/export

> > > It seems like there is some support for adding "When used in conjunction > > with --analyze in stages..." to the beginning of the sentence. I'll give > > it another day or two for any further discussion before committing. > > Here is what I have staged for commit. > +1

Re: vacuumdb changes for stats import/export

On Mon, Jul 28, 2025 at 01:46:34PM -0500, Nathan Bossart wrote: > On Mon, Jul 28, 2025 at 09:22:29AM -0700, David G. Johnston wrote: >> On Monday, July 28, 2025, Frédéric Yhuel wrote: >>> On 7/28/25 16:47, Nathan Bossart wrote: Obviously, this wording isn't clear enough. We might need to eit

Re: restore_command return code behaviour

On Mon, Jul 28, 2025 at 3:38 PM David G. Johnston wrote: > On Monday, July 28, 2025, Jacob Champion > wrote: >> RestoreArchivedFile() has a special case for SIGTERM, though? > > I don’t see anything calling out sigterm by name. It's got a comment explaining the separate behavior, right before t

Re: Doc update proposal for the note on log_statement in the runtime config for logging page

On Tue, Jul 29, 2025 at 11:46 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > > > On Tue, Jul 29, 2025, 10:07 Daniel Bauman wrote: > >> >> The tradeoff to ignore errors and not fsync every log absolutely makes >> sense to me. It's just something it would be beneficial for users to be

Re: Support getrandom() for pg_strong_random() source

On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut wrote: > The POSIX description of getentropy() says: > > "The intended use of this function is to create a seed for other > pseudo-random number generators." > > So using getentropy() for generating the random numbers that are passed > back to the a

Re: Making type Datum be 8 bytes everywhere

[ getting back to looking at this ] Andres Freund writes: > On 2025-07-17 20:09:57 -0400, Tom Lane wrote: >> The attached patch switches to 8-byte Datums everywhere, but >> doesn't make any effort to remove the now-dead code. > Thanks for writing that! > Interestingly it generates a *lot* of war

Assertion failure in pgbench

Hi, I encountered the following assertion failure in pgbench on the current master: Assertion failed: (res == ((void*)0)), function discardUntilSync, file pgbench.c, line 3515. Abort trap: 6 This can be reliably reproduced with the following steps: $ psql -c "A

Re: teach pg_upgrade to handle in-place tablespaces

Committed. -- nathan

Re: Making type Datum be 8 bytes everywhere

Nazir Bilal Yavuz writes: > On Wed, 23 Jul 2025 at 22:00, Tom Lane wrote: >> I'm disinclined to put in a huge amount of effort looking for the >> worst case. We established long ago that we weren't going to >> optimize for 32-bit anymore. So as long as this doesn't completely >> tank performanc

Re: Improve prep_buildtree

On Wed, Jul 30, 2025 at 6:35 AM Tom Lane wrote: > For this purpose, I think it's better for us to rely on things we > control than things Meson controls. Adding a new top-level directory > is rare enough that I don't see a problem with needing to update > prep_buildtree. +1. (This approach shoul

Re: Support getrandom() for pg_strong_random() source

On 30.07.25 13:55, Daniel Gustafsson wrote: The point still stands that the number of installations without OpenSSL support is approximately zero, so what is the purpose of this patch if approximately no one will be able to use it? The main usecase I've heard discussed (mostly in hallway tra

Re: pg_dump --with-* options

On Wed, 2025-07-30 at 10:23 +0200, Álvaro Herrera wrote: > Maybe we should invent a new > switch, something like >   --include=[schema,data,statistics] > with which users can give one or more comma-separated types to be > included in the dump.  Robert Treat brought up a similar idea before: http

Re: Improve prep_buildtree

Peter Eisentraut writes: > On 30.07.25 10:28, Nazir Bilal Yavuz wrote: >> Meson looks for ${builddir}/meson-private/coredata.dat file to >> understand if the directory is a build directory [1]. I am just >> wondering if you tried this and found it complicated or did you try >> something else. > I

Re: Support getrandom() for pg_strong_random() source

Dagfinn Ilmari Mannsåker writes: > Masahiko Sawada writes: > >> On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion >> wrote: >>> >>> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote: >>> > My understanding of the problem is that it is a choice of efficiency >>> > vs entropy, and that it's not

RE: 024_add_drop_pub.pl might fail due to deadlock

Dear Ajin, > Attaching the updated patches with the changes you requested. I've > also added the unchanged patches for PG_18 and HEAD (PG_18_HEAD-v6*), > so that everything is together in one mail. Thanks for update, but the patch for PG18/HEAD seemed not to have Assert(). Can you modify like oth

Re: Enable data checksums by default

> On 30 Jul 2025, at 11:58, Laurenz Albe wrote: > > On Tue, 2025-07-29 at 20:24 +0200, Tomas Vondra wrote: >> So, what should we do with the PG18 open item? We (the RMT team) would >> like to know if we shall keep the checksums enabled by default, and if >> there's something that still needs to b

Re: Support getrandom() for pg_strong_random() source

> On 30 Jul 2025, at 13:10, Peter Eisentraut wrote: > > On 30.07.25 08:59, Masahiko Sawada wrote: >> I've updated the patch to support getentropy() instead of getrandom(). > > The point still stands that the number of installations without OpenSSL > support is approximately zero, so what is the

Re: Support getrandom() for pg_strong_random() source

Masahiko Sawada writes: > On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion > wrote: >> >> On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote: >> > My understanding of the problem is that it is a choice of efficiency >> > vs entropy, and that it's not really possible to have both parts of >> >

Re: Adding basic NUMA awareness

On 7/30/25 10:29, Jakub Wartak wrote: > On Mon, Jul 28, 2025 at 4:22 PM Tomas Vondra wrote: > > Hi Tomas, > > just a quick look here: > >> 2) The PGPROC part introduces a similar registry, [..] >> >> There's also a view pg_buffercache_pgproc. The pg_buffercache location >> is a bit bogus - it h

Re: Support getrandom() for pg_strong_random() source

On 30.07.25 08:59, Masahiko Sawada wrote: I've updated the patch to support getentropy() instead of getrandom(). The point still stands that the number of installations without OpenSSL support is approximately zero, so what is the purpose of this patch if approximately no one will be able to

Re: pg_basebackup and pg_switch_wal()

To note effectively that the problem comes from a fix in version 17 PostgreSQL: Release Notes Change file boundary handling of two WAL file name functions (Kyotaro Horiguchi, Andres Freund, Bruce Momjian) Regards, Fabrice On Wed, Jul 30, 2025 at

Re: Support getrandom() for pg_strong_random() source

On 22.07.25 13:11, Dagfinn Ilmari Mannsåker wrote: getrandom() is Linux-specific, while getentropy() is specified by POSIX (since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in 2017, musl 1.1.20 and FreeBSD 12

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

On Tue, 29 Jul 2025 at 06:57, Peter Smith wrote: > Here are the latest v15 patches. > > Changes include: > > PATCH 0002. > - README now says user should not tamper with VCI internal relations > - fixes/test the VACUUM bug -- fix provided by Japin [1] > - fixes/tests the reported segv for attempted

Re: Improve prep_buildtree

Hi, On Wed, 30 Jul 2025 at 12:32, Peter Eisentraut wrote: > > On 30.07.25 10:28, Nazir Bilal Yavuz wrote: > > On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote: > >> > >> To fix this, I first tried to devise a way to detect whether a given > >> directory is a build directory. But that seemed

Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET

Tomas Vondra writes: > On 7/22/25 13:18, Dagfinn Ilmari Mannsåker wrote: >> jian he writes: >> >>> On Thu, Jul 17, 2025 at 1:41 AM Dagfinn Ilmari Mannsåker >>> wrote: Hi hackers, These two patches are split out from my earlier thread about improving tab completion for

Re: Enable data checksums by default

On Tue, 2025-07-29 at 20:24 +0200, Tomas Vondra wrote: > So, what should we do with the PG18 open item? We (the RMT team) would > like to know if we shall keep the checksums enabled by default, and if > there's something that still needs to be done for PG18. I don't have a strong opinion, but I le

Re: 024_add_drop_pub.pl might fail due to deadlock

On Tue, Jul 29, 2025 at 10:45 PM Hayato Kuroda (Fujitsu) wrote: > > > > How do you feel the .diff file can be applied atop PG17 patch? It is > > > mainly > > > same as v4 patch but has some assertion. > > Sorry for my interrupted message. I noticed only I attached old version patch. > PSA the cor

Re: Improve prep_buildtree

On 30.07.25 10:28, Nazir Bilal Yavuz wrote: On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote: To fix this, I first tried to devise a way to detect whether a given directory is a build directory. But that seemed pretty complicated. Instead, I chose the simpler solution that we just enumera

Re: restore_command return code behaviour

Le mar. 29 juil. 2025 à 00:38, David G. Johnston a écrit : > On Monday, July 28, 2025, Jacob Champion > wrote: > >> On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston >> wrote: >> > I don’t understand calling out sigterm as an exception, the same >> abort-and-shutdown action happens there too. >

Re: Proposal: Out-of-Order NOTIFY via GUC to Improve LISTEN/NOTIFY Throughput

On Tue, Jul 22, 2025, at 14:48, Joel Jacobson wrote: > Benchmark from original post: ... > For a normal PostgreSQL with the CPU and storage on the same physical machine, > I think the results above clearly demonstrate that the global exclusive lock > is at least not the bottleneck, which I strongly

Re: pg_basebackup and pg_switch_wal()

Thanks Israel for these informations. In fact, I thought at first of a problem related to the version of pg_basebackup in version 17. I should have posted first on the barman github. Best regards, Fabrice On Wed, Jul 30, 2025 at 12:47 AM Israel Barth Rubio wrote: > Hello Fabrice, > > > But I d

Re: Adding basic NUMA awareness

On Mon, Jul 28, 2025 at 4:22 PM Tomas Vondra wrote: Hi Tomas, just a quick look here: > 2) The PGPROC part introduces a similar registry, [..] > > There's also a view pg_buffercache_pgproc. The pg_buffercache location > is a bit bogus - it has nothing to do with buffers, but it was good > enoug

Re: Logical Replication of sequences

On Wed, Jul 30, 2025 at 11:16 AM shveta malik wrote: > > On Mon, Jul 28, 2025 at 3:37 PM vignesh C wrote: > > > Thanks for the comments, the attached v20250728 version patch has the > > changes for the same. > > > Thanks for the patches, please find a few comments: > > 1) > WARNING: WITH clause

Re: Improve prep_buildtree

Hi, Thank you for working on this! On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote: > > To fix this, I first tried to devise a way to detect whether a given > directory is a build directory. But that seemed pretty complicated. > Instead, I chose the simpler solution that we just enumerate

Re: pg_dump --with-* options

On 2025-Jun-25, Fujii Masao wrote: > For the record, my vote is: default "off" for pg_dump and pg_dumpall, > and "on" for pg_restore. I don't know if this horse is already dead, so bear with me while I beat it a little more. > [...] we could simplify further: > > * Keep: --schema-only, --da

Re: track generic and custom plans in pg_stat_statements

On 30/7/2025 09:20, Michael Paquier wrote: On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote: The only comment I have is I think we need a NOT_SET member, so it can simplify the life of extensions that have code paths which may or may not have a PlannedStmt, such as pgss_store. Okay

Re: Broken ./configure checks for __cpuid() and __cpuidex()

On Wed, Jul 30, 2025 at 12:02:44PM +0900, Michael Paquier wrote: > On Tue, Jul 29, 2025 at 12:21:32AM -0700, Lukas Fittl wrote: >> FWIW, I looked again at the MinGW sources and I think you're right that >> intrin.h is likely also correct for MinGW. I originally thought that >> cpuid.h would be corr

Improve prep_buildtree

Since I started using meson regularly, I have put the build directory under the source directory, which appears to be the recommended convention. See for example https://mesonbuild.com/Quick-guide.html#compiling-a-meson-project Then, if I also want to create a build directory using configure/

Re: Reduce "Var IS [NOT] NULL" quals during constant folding

On Wed, Jul 30, 2025 at 3:17 PM Richard Guo wrote: > create table t (a int, b int, c int); > > explain (costs off) > select * from t t1 > natural join t t2 > natural join t t3 > natural join t t4 > natural join t t5 > natural join t t6 > natural join t t7 > natural join t t8 > natural join

RE: POC: enable logical decoding when wal_level = 'replica' without a server restart

Dear Sawada-san, While reading more, I found a race condition. In this case the effective_wal_level can be logical even when there is no logical slot. UpdateLogicalDecodingStatusEndOfRecovery() checks the number of slots of the logical slot then release the lock once. Then startup process acquir

Re: track generic and custom plans in pg_stat_statements

On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote: > The only comment I have is I think we need a NOT_SET > member, so it can simplify the life of extensions that have code > paths which may or may not have a PlannedStmt, such as > pgss_store. Okay by me for having a default that maps to

Re: Support getrandom() for pg_strong_random() source

On Tue, Jul 29, 2025 at 8:55 AM Jacob Champion wrote: > > On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote: > > My understanding of the problem is that it is a choice of efficiency > > vs entropy, and that it's not really possible to have both parts of > > the cake. Agreed. I think the opti