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

On Wed, 30 Jul 2025 at 14:49, Peter Smith wrote: > On Fri, Jul 25, 2025 at 1:58 PM Japin Li wrote: >> >> On Wed, 23 Jul 2025 at 14:07, Peter Smith wrote: >> > On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote: >> > ... > ... >> >> >> >> Or is it by design that users are unable to read the internal

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

On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra wrote: > Does this mean we can close the PG18 open item tracking this? > > * virtual generated columns and planning speed > Owner: Peter Eisentraut > > > If I understand correctly, the commits went only to master, which means > PG18 still does the

Re: Logical Replication of sequences

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 parameters do not affect sequence synchronization a) How about: WITH cl

Re: Test instability when pg_dump orders by OID

Hello Noah, 07.07.2025 22:26, Noah Misch wrote: A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and "notnull_parent_upg nn" for the schema diff test that commit 172259afb563d35001410dc6daad78b250924038 added in v18: @@ -436873,14 +436873,14 @@ ALTER TABLE public.insert

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

On Fri, Jul 25, 2025 at 1:58 PM Japin Li wrote: > > On Wed, 23 Jul 2025 at 14:07, Peter Smith wrote: > > On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote: > > ... ... > >> > >> Or is it by design that users are unable to read the internal relations? > >> > > > > IIUC, those VCI internal relations

Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row

hi. rebase. From b3b2d794c83b36cf129d917d527ebf2cac46ca3b Mon Sep 17 00:00:00 2001 From: jian he Date: Wed, 30 Jul 2025 11:06:17 +0800 Subject: [PATCH v19 1/1] COPY (on_error set_null) Current grammar makes us unable to use "on_error null". if we did it, then in all the COPY command options's va

Re: Compilation error with buildtype = release

On Tue, Jul 29, 2025 at 6:36 PM Tom Lane wrote: > > Ashutosh Bapat writes: > > I am seeing following error only with buildtype = release > > Interesting. I noticed skink showing the same thing as a warning, > but no other BF animals have shown it (yet anyway). > > > Looking at the function, relt

Re: speedup COPY TO for partitioned table.

On Mon, Jul 28, 2025 at 9:22 AM torikoshia wrote: > > I think the behavior for materialized views can be described along with > that for partitioned tables. For example: > > COPY TO can be used with plain > tables, populated materialized views and partitioned tables. > For exampl

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

On Tue, Jul 29, 2025 at 12:21:32AM -0700, Lukas Fittl wrote: > Its worth noting that __get_cpuid_count and __cpuidex are not fully > equivalent (which is part of why GCC added __cpuidex despite already > having __get_cpuid_count), but in any case the current code doesn't care > about that, since it

Re: analyze-in-stages post upgrade questions

On Fri, Jul 11, 2025 at 7:42 PM Mircea Cadariu wrote: > > On 11/07/2025 10:51, Laurenz Albe wrote: > > > Good idea; done in the attached version 2 of the patch. > > Thanks! Looks good. I have set the status of the Commitfest entry to > "Ready for Committer". I've started reviewing the patch since

Re: Non-text mode for pg_dumpall

On 2025-07-29 Tu 4:34 PM, Noah Misch wrote: On Tue, Jul 29, 2025 at 04:09:13PM -0400, Andrew Dunstan wrote: here's a reversion patch for master. This reverts parts or all of the following commits: I briefly looked through this. The biggest non-reverted part is, I think, c1da728 "Move co

Re: pg_dump --with-* options

On Tue, 2025-07-29 at 20:22 +0200, Álvaro Herrera wrote: > Please move the switches themselves out of the translatable message, > otherwise there are too many of them.  For instance, Thank you for looking, v2 attached. Regards, Jeff Davis From 61b0239f17a1c7220de32699e95c6b365accbb88 Mon

new environment variable INITDB_LOCALE_PROVIDER

$SUBJECT makes it easier to test other providers, especially the regression tests. For this to be useful, it should avoid throwing an error for plain "initdb" (without locale flags specified), which means we need defaults for the builtin locale or the ICU locale. I chose "C.UTF-8" and "und" (we co

Re: libxml2 author overwhelmed with security requests

En 21/07/25 1:16 a. m., Sandeep Thakkar escribió: On Fri, Jun 20, 2025 at 2:42 AM Tom Lane wrote: Pavel Stehule writes: > Own implementation of SQL/XML generating functions like XMLFOREST or > XMLELEMENT should not be too > difficult. Significantly more difficult problem is

Re: pg_basebackup and pg_switch_wal()

Hello Fabrice, > But I do not understand this error with the barman wrapper: > > Backup completed (start time: 2025-07-26 21:45:07.238223, elapsed time: 19 seconds) > Waiting for the WAL file 00030B3F000C from server 'x_service' (max: 600 seconds) > Processing xlog segments from stream

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

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, passed This is properly isolated, only available when turned on. I ran t

Re: C11 / VS 2019

On Wed, 30 Jul 2025 at 00:57, Tom Lane wrote: > > David Rowley writes: > > On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote: > >> Note that gcc and clang switched to C11 by default a long time ago > >> (gcc-5 and clang-3.6), so for most users all these tests won't need to > >> do anything.

Re: track generic and custom plans in pg_stat_statements

> > Attached is my counter-proposal, where I have settled down to four > > categories of PlannedStmt: > > - "standard" PlannedStmt, when going through the planner. > > - internally-generated "fake" PlannedStmt. > > - custom cache > > - generic cache > > Thanks for the update! I plan on reviewing th

Re: BackendKeyData is mandatory?

On Tue, 29 Jul 2025 at 22:42, Heikki Linnakangas wrote: > I'm not quite sold on the change to PQcancelCreate(). The current > behavior seems nicer: if cancellation is not available because the > server didn't send a cancellation key, PQcancelCreate() returns a > (cancel) connection object that's i

Re: BackendKeyData is mandatory?

Thanks for digging into this! On 03/07/2025 09:13, Jelte Fennema-Nio wrote: On Thu Jul 3, 2025 at 2:03 AM CEST, Jacob Champion wrote: On Wed, Jul 2, 2025 at 3:18 PM Jelte Fennema-Nio wrote: I will hold off on detailed review until Heikki gives an opinion on the design (or we get closer to the

Re: Non-text mode for pg_dumpall

On Tue, Jul 29, 2025 at 04:09:13PM -0400, Andrew Dunstan wrote: > here's a reversion patch for master. > This reverts parts or all of the following commits: I briefly looked through this. The biggest non-reverted part is, I think, c1da728 "Move common pg_dump code related to connections to a

Re: Non-text mode for pg_dumpall

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 suggestion? pg_dumpall would continue to produce globa

Re: Regression with large XML data input

Jim Jones writes: > I also didn't spot any leaks, but I was rather hesitant to remove it > after re-reading the code, since there's still a risk of leakage if the > caller fails to free parsed_nodes in case of an error. However, it seems > that only xmltotext_with_options relies on this, and even

Re: Regression with large XML data input

On 29.07.25 17:27, Tom Lane wrote: > Re-reading the prior thread, I see that my memory above is quite > faulty: we added the node_list intermediate variable as a way to > detect errors when the return code from xmlParseBalancedChunkMemory > couldn't be trusted. So I think you're right to questi

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

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 > aware of. Particularly those concerned with auditing. > The main question is where to put such i

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

On 7/22/25 04:55, Richard Guo wrote: > On Wed, Jul 16, 2025 at 10:57 AM Richard Guo wrote: >> On Wed, Jul 9, 2025 at 3:32 PM Richard Guo wrote: >>> Here is a new rebase. I moved the call to preprocess_relation_rtes to >>> a later point within convert_EXISTS_sublink_to_join, so we can avoid >>> t

Re: [Patch] add new parameter to pg_replication_origin_session_setup

On Mon, Jul 29, 2025 at 8:13 AM Amit Kapila wrote: > That is true but I still feel there has to be some mechanism where we > can catch and give an ERROR to the user, if it doesn't follow the > same. For example, pg_replication_origin_advance() always allows going > backwards in terms of LSN which

Re: pg_dump --with-* options

On Wed, 2025-06-18 at 10:21 -0700, Jeff Davis wrote: > On Wed, 2025-06-18 at 10:43 -0500, Nathan Bossart wrote: > > IIUC the current proposal is to: > > > > * Dump/restore stats by default. We don't have a consensus for that, so unless a few people make an abrupt turnaround, this will remain off

Re: Enable data checksums by default

Hi! 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. We don't have a strong opinion either way, but there doesn't seem to be much happening on this

Re: pg_dump --with-* options

On 2025-Jul-29, Jeff Davis wrote: > + /* reject conflicting "only-" and "with-" options */ > + if (data_only && with_schema) > + pg_fatal("options -a/--data-only and --with-schema cannot be > used together"); > + if (data_only && with_statistics) > + pg_fatal("

Re: IPC/MultixactCreation on the Standby server

> On 29 Jul 2025, at 12:17, Dmitry wrote: > > But on the master, some of the requests then fail with an error, apparently > invalid multixact's remain in the pages. Thanks! That's a bug in my patch. I do not understand it yet. I've reproduced it with your original workload. Most of errors

Re: pg_dump --with-* options

On Thu, 2025-07-10 at 10:42 -0700, Jeff Davis wrote: > On Wed, 2025-06-18 at 10:21 -0700, Jeff Davis wrote: > >   * reject the combination of an "only" option and a "with" option > > There seems to be a rough consensus on this point. Patch attached. Regards, Jeff Davis From f668a980ca73

Re: pg_dump --with-* options

On Fri, 2025-07-11 at 09:12 +0900, Fujii Masao wrote: > But to do that, we'd either need to make pg_dump dump statistics > by default, or allow redundant options like --statistics in > pg_restore, > even though it already restores statistics by default. Redundant options might be annoying, but I d

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

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 varous RESET forms >>> (https://

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

On Tue, Jul 29, 2025 at 8:46 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Monday, July 28, 2025, Daniel Bauman wrote: > >> The doc fragment you shared is explaining to customers that basic syntax >> checks are done before postgres gets to logging the transaction. >> I don't thin

Re: AIO v2.5

[RMT hat] On Tue, Jul 22, 2025 at 03:51:12PM +0200, Tomas Vondra wrote: > In general, it doesn't change the earlier conclusions at all. Most of > the earlier observations apply to these results from these machines with > reasonably different types of storage. So I still think we should stick > to

Re: Support getrandom() for pg_strong_random() source

Jacob Champion writes: > On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote: > >> Could getentropy() be more efficient at the end on most platforms, >> meaning that this could limit the meaning of having a GUC switch? > > I don't know. [2] implies that the performance comparison depends on >

Re: Support getrandom() for pg_strong_random() source

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. That was my understanding too, but then [1] called that into question. If -- and I don't

Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table

Hi, On Wed, 23 Jul 2025 19:38:19 +0900 Etsuro Fujita wrote: > Hi, > > On Sat, Jul 19, 2025 at 12:53 AM Jehan-Guillaume de Rorthais > wrote: > > […] > > Please, find in attachment the old patch forbidding more than one row to be > > deleted/updated from postgresExecForeignDelete and > > postgre

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

On Monday, July 28, 2025, Daniel Bauman wrote: > The doc fragment you shared is explaining to customers that basic syntax > checks are done before postgres gets to logging the transaction. > I don't think that is the same as clearly explaining to users statement > logging happens before execution

Re: split func.sgml to separated individual sgml files

Andrew Dunstan writes: > OK. I'm inclined to do this after the CF finishes, to avoid collisions > with other patches. I assume it's going to make the CFbot fairly unhappy. +1 for proceeding that way. (I did not look at whether the proposed changes are sane, but I agree that this'll inevitably b

Re: split func.sgml to separated individual sgml files

On 2025-07-29 Tu 2:15 AM, jian he wrote: hi. after run the v2 python script and ``git apply v2-0001-update-filelist.sgml-allfiles.sgml.no-cfbot`` git status -u shows: Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git restore ..." to discard

Re: Regression with large XML data input

Jim Jones writes: > On 29.07.25 14:11, Tom Lane wrote: >> In the original coding, there was a hazard of the node list getting >> leaked if the caller passed parsed_nodes == NULL. Or at least I >> thought there was. It may be that all releases of libxml2 are smart >> enough to free the node list

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

The doc fragment you shared is explaining to customers that basic syntax checks are done before postgres gets to logging the transaction. I don't think that is the same as clearly explaining to users statement logging happens before execution. At least for me, as a user and reader of the docs but n

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

Here's where I think the logging is happening. https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L1070 It seems like the log is happening before application of the transaction, not after. So consistency is best effort. ie - a crash after the log but before the transactio

Re: Making pgfdw_report_error statically analyzable

I wrote: > I'll run with Alvaro's suggestion, then. And done. In the event I realized that there's no point in back-patching this, because 80aa9848b already changed all the call sites of pgfdw_report_error, so we're already going to have issues back-patching any fixes that touch those.

Re: event trigger support for PL/Python

út 29. 7. 2025 v 14:53 odesílatel Euler Taveira napsal: > On Sun, Jul 20, 2025, at 3:07 AM, Pavel Stehule wrote: > > it is registered in commitfest app? > > > > The patch looks well > > > Ops. I forgot to create one. I registered it now. > > https://commitfest.postgresql.org/patch/5939/ > > Thank

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

On Mon, Jul 28, 2025 at 07:35:51PM -0400, Bruce Momjian wrote: > On Mon, Jul 28, 2025 at 04:24:14PM -0700, Daniel Bauman wrote: > > Here's where I think the logging is happening. https://github.com/postgres/ > > postgres/blob/master/src/backend/tcop/postgres.c#L1070 > > It seems like the log is hap

Re: Use merge-based matching for MCVs in eqjoinsel

On 21.07.2025 16:55, Ilia Evdokimov wrote: While analyzing planner performance on JOB with default_statistics_target = 1000, I noticed that a significant portion of planning time is spent inside the eqjoinsel() function. According to perf, in most JOB queries at default_statistics_target = 1

Re: Regression with large XML data input

On 29.07.25 14:11, Tom Lane wrote: > In the original coding, there was a hazard of the node list getting > leaked if the caller passed parsed_nodes == NULL. Or at least I > thought there was. It may be that all releases of libxml2 are smart > enough to free the node list if there's no way to p

Re: Adding wait events statistics

On Mon, Jul 28, 2025 at 8:35 AM Bertrand Drouvot wrote: > Focusing on LWLocks, I think that for example the OidGenLock one is one > it would be interesting to have the duration for. That way one could start to > investigate if there is a very long run of used OID values with no gaps in > TOAST tab

Re: Making pgfdw_report_error statically analyzable

Robert Haas writes: > On Mon, Jul 28, 2025 at 5:30 PM Tom Lane wrote: >> =?utf-8?Q?=C3=81lvaro?= Herrera writes: >>> Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel, >>> but complement it with pgfdw_report() that takes the elevel as argument, >>> asserting that it's less th

Re: Enhancing Memory Context Statistics Reporting

Hi, Please find attached an updated patch. It contains the following changes. 1. It needed a rebase as highlighted by cfbot . The method for adding an LWLock was updated in commit-2047ad068139f0b8c6da73d0b845ca9ba30fb33d, so the patch has been adjusted t

Re: Making pgfdw_report_error statically analyzable

On Mon, Jul 28, 2025 at 5:30 PM Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera writes: > > Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel, > > but complement it with pgfdw_report() that takes the elevel as argument, > > asserting that it's less than ERROR? Then the call

Re: encode/decode support for base64url

On Jul 29, 2025, at 08:25, Daniel Gustafsson wrote: > The attached version also adds a commit message, tweaks the documentation > along > with a few small changes to error message handling etc. This looks great. One nit my editor noticed: This line: +-- Round-trip test for all lengths from 0–4

Re: Better HINT message for "unexpected data beyond EOF"

On Mon, Jul 28, 2025 at 2:42 PM Nathan Bossart wrote: > On Mon, Jul 28, 2025 at 11:22:49AM -0400, Robert Haas wrote: > > Committed. I removed the changes from the .po files since we don't > > routinely update those, and I rewrote your proposal commit message. > > nitpick: It looks like this needs

Re: pg_basebackup and pg_switch_wal()

Thanks for answering Sergei. ok in file postgres/src/backend/access/transam/xlog.c function void do_pg_backup_stop(BackupState *state, bool waitforarchive) there is /* * Force a switch to a new xlog segment file, so that the backup is * valid as soon as archiver moves out the current segment fil

Re: Compilation error with buildtype = release

Ashutosh Bapat writes: > I am seeing following error only with buildtype = release Interesting. I noticed skink showing the same thing as a warning, but no other BF animals have shown it (yet anyway). > Looking at the function, reltuples is indeed initialized in all the > cases. All the relevan

Re: C11 / VS 2019

David Rowley writes: > On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote: >> Note that gcc and clang switched to C11 by default a long time ago >> (gcc-5 and clang-3.6), so for most users all these tests won't need to >> do anything. If you want to test it, you could simulate an older >> defa

Re: 024_add_drop_pub.pl might fail due to deadlock

On Tue, 29 Jul 2025 at 14:46, Ajin Cherian wrote: > > On Tue, Jul 29, 2025 at 1:13 PM Amit Kapila wrote: > > > > Yes, that makes sense to me. For HEAD and PG18, we can still add a new > > argument to the API. For other bank branches, it is better to use a > > new Ex function as suggested by Kurod

Re: event trigger support for PL/Python

On Sun, Jul 20, 2025, at 3:07 AM, Pavel Stehule wrote: > it is registered in commitfest app? > > The patch looks well > Ops. I forgot to create one. I registered it now. https://commitfest.postgresql.org/patch/5939/ -- Euler Taveira EDB https://www.enterprisedb.com/

Re: Improve error reporting in 027_stream_regress test

Michael Paquier writes: > On Tue, Jul 29, 2025 at 12:41:39AM -0400, Tom Lane wrote: >> There is something strange happening on mamba --- not sure what, >> but its cycle time for the past week has been a lot more than normal. > We are getting PQPING_NO_RESPONSE meaning a lack of report activity >

Re: refactor backend type lists

On Mon, Jul 28, 2025, at 6:13 PM, Álvaro Herrera wrote: > I should have let you know that I spent some time on this today as well > to avoid duplicating efforts. Here are my patches, incorporating your > fixup -- I hadn't looked at your 0004 yet, so I wrote it differently, > passing the BackendTyp

RE: 024_add_drop_pub.pl might fail due to deadlock

> > 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 correct version. Best regards, Hayato Kuroda FUJITSU LIMITED kuroda.diffs Descript

Compilation error with buildtype = release

Hi Tom, I am seeing following error only with buildtype = release FAILED: contrib/postgres_fdw/postgres_fdw.so.p/postgres_fdw.c.o cc -Icontrib/postgres_fdw/postgres_fdw.so.p -Isrc/include -I../../coderoot/pg/src/include -Isrc/interfaces/libpq -I../../coderoot/pg/src/interfaces/libpq -fdiagnostics-

RE: 024_add_drop_pub.pl might fail due to deadlock

> How do you feel the .diff file can be applied atop PG17 patch? It is mainly > same as v4 patch but has some assertion. Best regards, Hayato Kuroda FUJITSU LIMITED

RE: 024_add_drop_pub.pl might fail due to deadlock

Dear Ajin, > I have added "Ex functions" for back branches (PG_17 and earlier) , > which also have Asserts for making sure locks are taken. For PG_18 and > HEAD, I've used the extra parameter already_locked. > PG_14_15-v6-0001-Fix-a-deadlock-during-ALTER-SUBSCRIPTION.-DROP-PU.p > atch > is for bot

Re: encode/decode support for base64url

> On 12 Jul 2025, at 21:40, David E. Wheeler wrote: > Thank you! This looks great. The attached revision makes a a couple of minor > changes: I also had a look at this today and agree that it looks pretty close to being done, and a feature we IMHO would like to have. > * I kind of expected pg_

Re: Regression with large XML data input

Jim Jones writes: > Out of curiosity, what's the reasoning behind keeping node_list instead > of directly using parsed_nodes in the xmlParseBalancedChunkMemory call? In the original coding, there was a hazard of the node list getting leaked if the caller passed parsed_nodes == NULL. Or at least

page_collect_tuples without long lock on page (Was Re: IPC/MultixactCreation on the Standby server)

17.07.2025 21:34, Andrey Borodin пишет: >> On 30 Jun 2025, at 15:58, Andrey Borodin wrote: >> page_collect_tuples() holds a lock on the buffer while examining tuples >> visibility, having InterruptHoldoffCount > 0. Tuple visibility check might >> need WAL to go on, we have to wait until some nex

Re: 024_add_drop_pub.pl might fail due to deadlock

On Tue, Jul 29, 2025 at 4:26 PM vignesh C wrote: > > On Tue, 29 Jul 2025 at 14:46, Ajin Cherian wrote: > > > > On Tue, Jul 29, 2025 at 1:13 PM Amit Kapila wrote: > > > > > > Yes, that makes sense to me. For HEAD and PG18, we can still add a new > > > argument to the API. For other bank branches,

Re: 024_add_drop_pub.pl might fail due to deadlock

On Tue, 29 Jul 2025 at 14:46, Ajin Cherian wrote: > > On Tue, Jul 29, 2025 at 1:13 PM Amit Kapila wrote: > > > > Yes, that makes sense to me. For HEAD and PG18, we can still add a new > > argument to the API. For other bank branches, it is better to use a > > new Ex function as suggested by Kurod

Re: Logical replication launcher did not automatically restart when got SIGKILL

On Sun, Jul 27, 2025 at 3:13 PM cca5507 wrote: > > > I've attached an updated patch with that change. > > LGTM! I've pushed the patch. Thanks! Regards, -- Fujii Masao

Re: Regression with large XML data input

On 28.07.25 22:16, Tom Lane wrote: > Erik's v2 is slightly wrong as to the save-and-restore logic for > the KeepBlanks setting: we need to restore in the error path too, > and we'd better mark the save variable volatile since it's modified > inside the PG_TRY. I made some other cosmetic changes,

Re: pg_basebackup and pg_switch_wal()

Hello > This is not the case also when the backup is made from the primary? On primary it is handled in do_pg_backup_stop function (called from perform_base_backup after basebackup was transferred), without explicitly called pg_switch_wal from pg_basebackup. pg_basebackup can change this behavi

Re: Proposal: QUALIFY clause

On Tue, Jul 29, 2025 at 9:47 AM David Rowley wrote: > You should be pushing the qual to the lowest level that it's valid to > evaluate it at. We do this already for HAVING quals where those will > effectively be "transferred" to the WHERE clause when it's valid to do > so. I'd expect the same for

Re: C11 / VS 2019

On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote: > Note that gcc and clang switched to C11 by default a long time ago > (gcc-5 and clang-3.6), so for most users all these tests won't need to > do anything. If you want to test it, you could simulate an older > default like > > ./configure CC=

Re: ICU warnings during make installcheck and text_extensions test

Alexander Korotkov wrote at 2025-07-28 20:04: Hi, Oleg! Thank you for raising this issue. I don't think ignoring a warning is an option. The tests contain locale-sensitive orderings. Thus, if we don't manage to create a C-like locale, tests fail anyway for me. Ignoring tests is an unfavorable

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi, Dmitry! I went through the patches. Both of them applied with a small conflict in the parallel_schedule, which is easy to resolve. + ExecClearTuple(insertslot); + + memcpy(insertslot->tts_values, srcslot->tts_values, + sizeof(Datum) * srcslot->

Re: Extension security improvement: Add support for extensions with an owned schema

On Wed Jul 23, 2025 at 7:12 PM CEST, Artem Gavrilov wrote: Hello Jelte, 1) I noticed that pg_dump changes weren't covered with tests. 2) I assume these error messages may be confusing, especially first one: Attached is an updated version that addresses these issues. From 7cc55c4e3a1fe2b5d958a

Re: Fix bug with accessing to temporary tables of other sessions

Hi, On Mon, Jul 28, 2025 at 10:43 AM Stepan Neretin wrote: > > > Your patch for securing cross-session temp table access is a great > improvement. The RVR_OTHER_TEMP_OK flag elegantly handles the DROP case while > keeping the main restriction in place. > > For schema name validation, an exact s

Re: Unnecessary delay in streaming replication due to replay lag

Thanks Huansong for reviewing the patch, and I have addressed all the above-mentioned points. PFA rebased patch. Thanks & Regards, Sunil S v7-0001-Introduce-feature-to-start-WAL-receiver-eagerly.patch Description: Binary data v7-0002-Test-WAL-receiver-early-start-upon-reaching-consi.patch De

Re: 024_add_drop_pub.pl might fail due to deadlock

On Tue, Jul 29, 2025 at 1:13 PM Amit Kapila wrote: > > Yes, that makes sense to me. For HEAD and PG18, we can still add a new > argument to the API. For other bank branches, it is better to use a > new Ex function as suggested by Kuroda-San. > Here are the updated patches. I have added "Ex funct

Making WAL archiving faster — multi-file support and async ideas

Hi hackers, We’ve been thinking about how to make WAL archiving faster. This topic was previously discussed in [1], and we’ve taken a first step by implementing the attached patch, which adds support for archiving multiple WAL files in one go. The idea is straightforward: instead of invoking the

Re: A performance regression issue with Memoize

On 29/7/2025 06:30, David Rowley wrote: On Tue, 29 Jul 2025 at 16:01, Richard Guo wrote: Another possible direction is to support runtime plan correction or feedback loops. We've always followed a "plan-first, execute-next" approach so far. But perhaps we could extend that by monitoring plan

Re: delimiter inconsistency in generate-wait_event_types.pl

> On 29 Jul 2025, at 06:56, Kyotaro Horiguchi wrote: > I got bitten by an inconsistency introduced about two years ago. In > the script generate-wait_event_types.pl, the intermediate line format > is parsed using a regular expression that allows multiple tab > characters between fields. However,

pg_basebackup and pg_switch_wal()

Hi, I read the doc concerning pg_basebackup pg_basebackup cannot force the standby to switch to a new WAL file at the end of backup. When you are using -X none, if write activity on the primary is low, pg_basebackup may need to wait a long time for the last WAL file required for the backup to be

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

On Mon, Jul 28, 2025 at 10:30 PM Michael Paquier wrote: > meson.build does not check for the second pieces if the > first checks pass. configure checks each of these four APIs > individually, and all of them detected in MinGW. So we can simply > mimick in ./configure what meson does like in the

Re: IPC/MultixactCreation on the Standby server

I'll duplicate the message, the previous one turned out to have poor formatting, sorry. On 28.07.2025 15:49, Andrey Borodin wrote: I also attach a version for PG17, maybe Dmitry could try to reproduce the problem with this patch. Andrey, thank you very much for your work, and also thanks to Álv