Re: Sequence Access Methods, round two

On Mon, 18 Aug 2025 at 09:49, Michael Paquier wrote: > > We could just > reuse AlterColumn, saving from the extra sub-command. What do you > think? Yes, this resonates with me better. > Rebased the rest as attached, for now. I have a small enhancement to the patch set. In v17-0003: ``` reshke

Re: Enhancing Memory Context Statistics Reporting

On 2025-08-14 07:35, Rahila Syed wrote: Hi Torikoshia, Thank you for reviewing the patch. This function is added at the end of Table "9.96. Server Signaling Functions", but since pg_get_process_memory_contexts outputs essentially the same information as pg_log_backend_memory_contexts, it might

Re: C11 / VS 2019

Hi, On 2025-07-18 14:12:34 +0300, Peter Eisentraut wrote: > I also moved the test a bit earlier in meson.build, as a separate patch, > because between the place where the compiler is first set up and the place > where we detected the C99 options, if any, there were already some tests run > that us

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

David Rowley writes: > I've purposefully left references to HASH_DEBUG in the "Original > comments" section near the top of dynahash.c. That comment also > references function names that no longer exist. Hm, there is actually no part of that comment para that is accurate anymore, so I cannot imag

Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

On Sun, Aug 17, 2025 at 11:57 AM Naga Appani wrote: > On Fri, Aug 8, 2025 at 4:33 AM Ashutosh Bapat > wrote: > > > In case each member starts consuming more or less space than it does > > today what would be the basis of triggering wraparound? Space or > > number of members? I think we should me

Re: Identifying function-lookup failures due to argument name mismatches

On Thu, Aug 14, 2025 at 9:18 PM Tom Lane wrote: > I wrote: > > Another thing not to like is that it seems like this is doing violence > > to several APIs in exchange for not very much improvement in the error > > messages. I feel like maybe we ought to be trying for more > > specificity about add

Re: SQL Property Graph Queries (SQL/PGQ)

Hi Peter, On Mon, Aug 11, 2025 at 7:12 PM Peter Eisentraut wrote: > > I have browsed this patch set a bit to get myself up to date. > > General thoughts: > > This is a large patch set, and it's not going to be perfect at the first > try. Especially, some of the parsing rules, query semantics, th

RE: Conflict detection for update_deleted in logical replication

On Monday, August 18, 2025 2:32 PM Dilip Kumar wrote: > > On Mon, Aug 18, 2025 at 10:36 AM Amit Kapila > wrote: > > > > > --- > > > Even if an apply worker disables retaining dead tuples due to > > > max_conflict_retention_duration, it enables again after the server > > > restarts. > > > > > > >

Re: make -C src/test/isolation failure in index-killtuples due to btree_gist

Hi, On 2025-08-18 08:57:13 +0900, Michael Paquier wrote: > The following command fails, because btree_gist is not installed in > the context of the isolation tests: > make -C src/test/isolation/ > > This test has been added recently by 377b7ab14524. Some efforts have > been done lately to remove

Re: Retail DDL

Jelte Fennema-Nio writes: > On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote: >> So I don't really buy Álvaro's argument above. It'd be better >> to design to some concrete requirement that isn't either of >> those. Unfortunately, it's not clear to me that anyone has >> a concrete use-case in mind

Re: Plan caching and serialization for reuse across executions

On 18/8/2025 13:50, Kirill Reshke wrote: Hi! On Sun, 17 Aug 2025 at 23:34, Xuan Chen wrote: - Any relevant references in the source code (planner, plancache.c, executor) that I should study would be very helpful. Here is extension implementing saving and restoring plans[0] [0]https://git

Re: Plan caching and serialization for reuse across executions

On 16/8/2025 14:32, Xuan Chen wrote: Hi hackers, I am currently exploring whether it is possible to cache a plan generated by the PostgreSQL planner and reuse it across later executions. I understand that there are existing mechanisms like PREPARE/EXECUTE and CachedPlan in plancache.c, but th

Re: Conflict detection for update_deleted in logical replication

On Mon, Aug 18, 2025 at 5:05 PM Zhijie Hou (Fujitsu) wrote: > > On Monday, August 18, 2025 2:32 PM Dilip Kumar wrote: > > > > On Mon, Aug 18, 2025 at 10:36 AM Amit Kapila > > wrote: > > > > > > > --- > > > > Even if an apply worker disables retaining dead tuples due to > > > > max_conflict_reten

Re: Plan caching and serialization for reuse across executions

Andrei Lepikhov writes: > I wouldn't recommend this obsolete version of the extension. Since the > QueryId was introduced, we have redesigned it extensively, with the > basic idea that QueryId serves as a 'query plan class' and that matching > parse trees provide a proof of matching incoming qu

Re: Retail DDL

On Mon, 18 Aug 2025 at 15:57, Tom Lane wrote: > You haven't actually defined what "this" is. For starters, do you > really want this output to be included in \d? Seems like one part > or the other of such output would be clutter, so I'd be more minded > to leave \d alone and invent some new comm

Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

Hi, > I'd like to propose a backward-compatible extension to the PostgreSQL > Frontend/Backend Protocol that would allow servers to send command metadata > back to clients alongside query results. > > ## Background & Motivation > > Coming from a MySQL background, I've found PostgreSQL's lack of

Re: Support getrandom() for pg_strong_random() source

On Thu, Aug 14, 2025 at 3:16 PM Masahiko Sawada wrote: > > On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion > wrote: > > > So, my next question: is getrandom() always preferable to /dev/urandom? > > I believe so. While /dev/urandom source should be kept as a fallback > for older kernels, we should u

Re: When deleting the plpgsql function, release the CachedPlan of the function

On Mon, 18 Aug 2025 at 08:51, zengman wrote: > > Hi, hackers > > I have observed an issue where the CachedPlan corresponding to a > function/procedure is not released when we execute the "DROP > FUNCTION\PROCEDURE" command. A patch to resolve this problem is attached. I'm trying to figure out h

Re: Retail DDL

On 2025-08-18 Mo 10:39 AM, Isaac Morland wrote: On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan wrote: > But the real issue is what to print.  In the case of a table, should > we also show its indexes?  What about foreign keys to or from other > tables?  If it's a partitioned table, w

Re: VM corruption on standby

Kirill Reshke writes: > On Sun, 17 Aug 2025 at 19:33, Tom Lane wrote: >> I do not like this patch one bit: it will replace one set of problems >> with another set, namely systems that fail to shut down. > I did not observe this during my by-hand testing. I am under the > impression that CRIT sec

Re: Improve LWLock tranche name visibility across backends

> 1 === > > +} LWLockTrancheNamesShmem; > > +} LWLockTrancheNamesStruct; > > Add LWLockTrancheNamesShmem and LWLockTrancheNamesStruct to > src/tools/pgindent/typedefs.list? done. > 2 === > > Maybe a comment before the above structs definitions to explain

Small issue with kerberos tests

Hi! Recently, I attempted to run the entire set of pg tests with PG_TEST_EXTRA="kerberos ..." on NetBSD but encountered a problem. The kerberos/001_auth and libpq/005_negotiate_encryption.pl test failed with an incomprehensible message: [01:55:38.737](3.698s) # setting up Kerberos # Running: krb5-

Re: Improve LWLock tranche name visibility across backends

> see v9 Sorry about the quick follow-up I was not happy with one of the comment updates in SyncLWLockTrancheNames. I updated it. Attached is v10, -- Sami v10-0001-Implement-a-DSA-for-LWLock-tranche-names.patch Description: Binary data v10-0002-Add-tests-for-LWLock-tranche-names-DSA.patch D

Re: Small issue with kerberos tests

Maxim Orlov writes: > Recently, I attempted to run the entire set of pg tests with > PG_TEST_EXTRA="kerberos ..." on NetBSD but encountered > a problem. The kerberos/001_auth and > libpq/005_negotiate_encryption.pl test failed with an incomprehensible > message: > [01:55:38.737](3.698s) # setting

Re: Add CHECK_FOR_INTERRUPTS in pg_buffercache_pages while scanning the buffers

On Fri, Aug 15, 2025 at 12:04 PM Masahiko Sawada wrote: > On Fri, Aug 15, 2025 at 2:33 AM SATYANARAYANA NARLAPURAM > wrote: > > > > Hi Masahiko, > > > > On Thu, Aug 14, 2025 at 4:57 PM Masahiko Sawada > wrote: > >> > >> On Fri, Aug 8, 2025 at 2:59 PM Masahiko Sawada > wrote: > >> > > >> > On T

Re: [Patch] add new parameter to pg_replication_origin_session_setup

> Your use looks good to me. So, maybe we can update the docs with the > dangers if the users of API doesn't follow commit order then it may > lead to data inconsistency should be sufficient. Additionally, we may > want to give an example as to how to use this API for parallel apply. That sounds r

Re: Plan caching and serialization for reuse across executions

Hi! On Sun, 17 Aug 2025 at 23:34, Xuan Chen wrote: > > - Any relevant references in the source code (planner, plancache.c, executor) > that I should study would be very helpful. Here is extension implementing saving and restoring plans[0] [0]https://github.com/postgrespro/sr_plan -- Best re

Re: Retail DDL

On 2025-08-18 Mo 9:57 AM, Tom Lane wrote: Jelte Fennema-Nio writes: On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote: So I don't really buy Álvaro's argument above. It'd be better to design to some concrete requirement that isn't either of those. Unfortunately, it's not clear to me that anyon

Re: Parallel Apply

On 18/08/2025 9:56 AM, Nisha Moond wrote: On Wed, Aug 13, 2025 at 4:17 PM Zhijie Hou (Fujitsu) wrote: Here is the initial POC patch for this idea. Thank you Hou-san for the patch. I did some performance benchmarking for the patch and overall, the results show substantial performance improv

Re: About Custom Aggregates, C Extensions and Memory

Marthin Laubscher writes: > Essentially the aggregate functions would still be front and centre as > defined for the user defined type, and though the user defined type itself > would be largely unaware of it, all the individual functions that manipulate > values of the UDT would go through the

Re: Retail DDL

On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan wrote: > > But the real issue is what to print. In the case of a table, should > > we also show its indexes? What about foreign keys to or from other > > tables? If it's a partitioned table, what about the partitions? > > I'm not sure this is as si

Re: When deleting the plpgsql function, release the CachedPlan of the function

Matthias van de Meent writes: > I'm trying to figure out how this patch is supposed to handle > concurrent sessions dropping a procedure that has cached plans. It doesn't, which is (one reason) why it's just a crude hack. A more appropriate solution would be to make plpgsql install a shared-cach

Re: fixing tsearch locale support

Peter Eisentraut wrote: > There is a PG18 open item to document this possible upgrade incompatibility. > > I think the following text could be added to the release notes: > > """ > The locale implementation underlying full-text search was improved. It > now observes the locale provider

Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

Hi, > - Multi-tenant applications tracking per-query resource consumption (buffer > hits/misses, CPU/IO time) BTW speaking of buffer hits/misses, you can already do this with EXPLAIN ANALYZE. -- Best regards, Aleksander Alekseev

Re: make -C src/test/isolation failure in index-killtuples due to btree_gist

Andres Freund writes: > On 2025-08-18 08:57:13 +0900, Michael Paquier wrote: >> The following command fails, because btree_gist is not installed in >> the context of the isolation tests: >> make -C src/test/isolation/ >> ... >> and it does not strike me as a good idea to begin doing that in the ma

Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

On Sun, Aug 17, 2025 at 5:25 PM Kir Shatrov wrote: > Is there interest in this type of protocol extension? There have been previous requests for baking custom trace IDs and WAL information into the protocol; the wiki is down right now but I recall some discussion at maybe the 2024 unconference?

Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

On Mon, Aug 18, 2025 at 9:05 AM Jacob Champion wrote: > There have been previous requests for baking custom trace IDs and WAL > information into the protocol; the wiki is down right now but I recall > some discussion at maybe the 2024 unconference? Wiki's back up: https://wiki.postgresql.org/wiki

Re: About Custom Aggregates, C Extensions and Memory

Tom Lane t...@sss.pgh.pa.us wrote: > Well, yeah, that's the problem. You can certainly maintain your own > persistent data structure somewhere, but then it's entirely on your head to > manage it and avoid memory leakage/bloating as you process more and more > data. T

Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations

Thanks for starting this thread! I do think it will be valuable to have an idea of how many calls were aborted. But I am not so sure about pg_stat_statements being the correct vehicle for this information. The pg_stat_statements view deals with stats the are updated when a statement completes exec

Re: POC: Parallel processing of indexes in autovacuum

On Mon, Aug 18, 2025 at 1:31 AM Daniil Davydov <3daniss...@gmail.com> wrote: > > > On Fri, Aug 15, 2025 at 3:41 AM Masahiko Sawada wrote: > > > > > 2. when an autovacuum worker (not parallel vacuum worker) who uses > > parallel vacuum gets SIGHUP, it errors out with the error message > > "paramete

fix misspelling of "tranche" in dsa.h

Attached is a patch to fix $subject, which appears to be the result of commit bb952c8c8b. -- nathan >From 1df952b77d4875466801b93477164cddd00f9eec Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Mon, 18 Aug 2025 16:04:06 -0500 Subject: [PATCH v1 1/1] Fix misspelling of "tranche" in dsa.h. O

Re: Improve hash join's handling of tuples with null join keys

Chao Li writes: > My comment was trying to say that if there are a lot of null join key tuples > in outer table, then hj_NullOuterTupleStore might use a lot of memory or swap > data to disk, which might lead to performance burden. So, I was thinking we > could keep the original logic for outer

Re: Improve LWLock tranche name visibility across backends

On Mon, Aug 18, 2025 at 01:06:42PM -0500, Sami Imseih wrote: > Attached is v10, I've been staring at the latest patch for a bit, and I'm a bit concerned at how much complexity it adds. I think it's a good idea to keep a local array of tranche names indexed by tranche ID, but the code for managing

Re: shmem_startup_hook called twice on Windows

> > "Because this hook is executed by the postmaster and invoked by backends via > > EXEC_BACKEND, it is essential to ensure that any code intended to run only > > during postmaster startup is properly protected against repeated execution. > > This can be enforced by verifying !IsUnderPostmaster be

Re: When deleting the plpgsql function, release the CachedPlan of the function

Sorry for the garbled characters. I am resending the original test results as an attachment. case.txt Description: Binary data

Re: VM corruption on standby

Hi! Thank you for putting attention to this. On Sun, 17 Aug 2025 at 19:33, Tom Lane wrote: > > Kirill Reshke writes: > > [ v1-0001-Do-not-exit-on-postmaster-death-ever-inside-CRIT-.patch ] > > I do not like this patch one bit: it will replace one set of problems > with another set, namely system

Re: ALTER DOMAIN ADD NOT NULL NOT VALID

On Mon, 18 Aug 2025 at 09:09, jian he wrote: > CREATE DOMAIN use ColConstraintElem. > that's why we do not support syntax: > ``create domain t1 as int not null not valid;`` > > we also do not support column constraints NOT NULL NOT VALID. > Like > ``create table t(a int not null not valid);`` > w

Re: POC: Parallel processing of indexes in autovacuum

Hi, Thank you very much for your comments! In this letter I'll answer both of your recent letters. On Fri, Aug 8, 2025 at 6:38 AM Masahiko Sawada wrote: > > Thank you for updating the patch. Here are some review comments. > > +/* Release all launched (i.e. reserved) parallel autovacuum wo

Re: When deleting the plpgsql function, release the CachedPlan of the function

Sorry for the garbled characters. I am resending the original test results as an attachment. result.pdf Description: Binary data

RE: ReplicationSlotRelease() crashes when the instance is in the single user mode

Dear Robert, > The use case for single-user mode is quite limited in general, but > most things work in single-user mode unless they are something that > intrinsically can't. For example, parallel query cannot be used in > single-user mode, because there is only one process. Replication > cannot w

Re: Retail DDL

On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote: > So I don't really buy Álvaro's argument above. It'd be better > to design to some concrete requirement that isn't either of > those. Unfortunately, it's not clear to me that anyone has > a concrete use-case in mind that isn't either of those. I ha

Re: ReplicationSlotRelease() crashes when the instance is in the single user mode

On Mon, Aug 18, 2025 at 08:47:27AM +, Hayato Kuroda (Fujitsu) wrote: > Here are updated patches. Based on the Robert's suggestion, I separated into > two parts. > 0001 fixed the original issue and 0002 prohibited the slot manipulation in > single-user mode. I want to focus on 0001 first becaus

Re: test_ddl_deparse: Rename test create_sequence_1

Hi! On Mon, 18 Aug 2025 at 12:40, Michael Paquier wrote: > > Hi all, > > While looking at this area of the code, I got confused by the choice > of using create_sequence_1 as name for one of the scripts in the test > module test_ddl_deparse. This is usually reserved for alternate > outputs, but w

Remove useless pointer advance in StatsShmemInit()

Hi hackers, While reviewing [1], I noticed a useless pointer advance and saw that StatsShmemInit() is doing the same. As StatsShmemInit() is existing code, let's fix it: the pointer is not used after its last advance, so that advance is unnecessary and can be removed. [1]: https://www.postgre

test_ddl_deparse: Rename test create_sequence_1

Hi all, While looking at this area of the code, I got confused by the choice of using create_sequence_1 as name for one of the scripts in the test module test_ddl_deparse. This is usually reserved for alternate outputs, but we don't need to rely on that in this case. How about renaming the test

Re: GB18030-2022 Support in PostgreSQL

On Mon, Aug 18, 2025 at 1:36 PM Chao Li wrote: > I think that patch could be separate, because the makefile changes are > generic to all map files. The current GB18030 patch doesn't depend on that > makefile patch at all. The makefile patch just makes build a little bit > easier upon map file c

RE: ReplicationSlotRelease() crashes when the instance is in the single user mode

Dear Paul, Mutaamba, Here are updated patches. Based on the Robert's suggestion, I separated into two parts. 0001 fixed the original issue and 0002 prohibited the slot manipulation in single-user mode. I want to focus on 0001 first because on one would argue it. All comments from you were includ

Re: fixing tsearch locale support

On 09.12.24 11:11, Peter Eisentraut wrote: lowerstr() and lowerstr_with_len() in ts_locale.c do the same thing as str_tolower(), except that the former don't use the common locale provider framework but instead use the global libc locale settings. This patch replaces uses of lowerstr*() with s

Re: VM corruption on standby

On Mon, 18 Aug 2025 at 13:15, I wrote: > > I do not like this patch one bit: it will replace one set of problems > > with another set, namely systems that fail to shut down. > > I did not observe this during my by-hand testing. I am sorry: I was wrong. This is exactly what happens in this test (mo

Re: Remove useless pointer advance in StatsShmemInit()

On Mon, Aug 18, 2025 at 09:04:59AM +, Bertrand Drouvot wrote: > As StatsShmemInit() is existing code, let's fix it: the pointer is not used > after > its last advance, so that advance is unnecessary and can be removed. > @@ -180,7 +180,6 @@ StatsShmemInit(void) * provides a small ef

Re: test_ddl_deparse: Rename test create_sequence_1

On Mon, Aug 18, 2025 at 02:05:20PM +0500, Kirill Reshke wrote: > Also, do we have any doc about regression file names/alternate > outputs? I did not find any. You have missed this one: https://www.postgresql.org/docs/devel/regress-variant.html -- Michael signature.asc Description: PGP signature

Re: Raw parse tree is not dumped to log

>> --- a/src/backend/tcop/postgres.c >> +++ b/src/backend/tcop/postgres.c >> @@ -649,6 +649,10 @@ pg_parse_query(const char *query_string) >> TRACE_POSTGRESQL_QUERY_PARSE_DONE(query_string); >> + if (Debug_print_raw_parse) >> + elog_node_display(LOG, "raw parse tree", raw_parsetree_list, >>

Re: Logical Replication of sequences

On Sat, 16 Aug 2025 at 14:15, Masahiko Sawada wrote: > > As I understand it, the logical replication of sequences implemented > by these patches shares the same user interface as table replication > (utilizing CREATE PUBLICATION and CREATE SUBSCRIPTION commands for > configuration). However, the u

Re: Detect buffer underflow in get_th()

On 13.12.24 09:57, Alexander Kuznetsov wrote: Hello, ping? 24.09.2024 17:52, Alexander Kuznetsov wrote: Hello, is there anything else we can help with or discuss in order to apply this fix? 24.07.2024 18:53, Alexander Kuznetsov пишет: 24.07.2024 18:39, Peter Eisentraut wrote: If it can't

Re: Raw parse tree is not dumped to log

On 2025/8/18 17:13, Tatsuo Ishii wrote: + if (unlikely(Debug_print_parse)) This should be: + if (unlikely(Debug_print_raw_parse)) My bad! Such a stupid mistake. Fixed. And I did a test by turning on/off the flag in postgres.conf, and raw parse tree is only dumped when "debug_print

Re: Remove useless pointer advance in StatsShmemInit()

Hi, On Mon, Aug 18, 2025 at 06:13:05PM +0900, Michael Paquier wrote: > On Mon, Aug 18, 2025 at 09:04:59AM +, Bertrand Drouvot wrote: > > As StatsShmemInit() is existing code, let's fix it: the pointer is not used > > after > > its last advance, so that advance is unnecessary and can be remove

Re: Improve LWLock tranche name visibility across backends

Hi, On Sat, Aug 16, 2025 at 10:18:05PM -0500, Sami Imseih wrote: > Attached is v8. Thanks for the new version! A few random comments about 0001: 1 === +} LWLockTrancheNamesShmem; +} LWLockTrancheNamesStruct; Add LWLockTrancheNamesShmem and LWLockTran

Re: Sequence Access Methods, round two

On Mon, Aug 18, 2025 at 06:15:05PM +0500, Kirill Reshke wrote: > Yes, this resonates with me better. After sleeping on it, yes, perhaps that's the right move. test_ddl_deparse reports the attributes as related to a sequence, but it's really how this is handled internally anyway with the internal c

Re: Potential deadlock in pgaio_io_wait()

Hi, On 2025-08-15 17:39:30 +1200, Thomas Munro wrote: > I discussed this off-list with Andres who provided the following review: > > * +1 for the analysis > * +1 for the solution > * his benchmark machine shows no regression under heavy IO submission > workload > * needs better comments > >

Re: VM corruption on standby

On Tue, 19 Aug 2025 at 11:13, Tom Lane wrote: > > Thomas Munro writes: > > On Tue, Aug 19, 2025 at 4:52 AM Tom Lane wrote: > >> But I'm of the opinion that proc_exit > >> is the wrong thing to use after seeing postmaster death, critical > >> section or no. We should assume that system integrity

Re: Plan caching and serialization for reuse across executions

Hi, On Mon, Aug 18, 2025 at 10:18:34AM -0400, Tom Lane wrote: > Andrei Lepikhov writes: > > I wouldn't recommend this obsolete version of the extension. Since the > > QueryId was introduced, we have redesigned it extensively, with the > > basic idea that QueryId serves as a 'query plan class' and

Re: Plan caching and serialization for reuse across executions

On 18/8/2025 16:18, Tom Lane wrote: Andrei Lepikhov writes: I wouldn't recommend this obsolete version of the extension. Since the QueryId was introduced, we have redesigned it extensively, with the basic idea that QueryId serves as a 'query plan class' and that matching parse trees provide a p

Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

On Mon, Aug 18, 2025 at 08:32:39PM -0500, Naga Appani wrote: > Thanks a lot for taking the time to review this patch and share your thoughts. > > Here’s a short summary of what has changed in v5: > - Added the new pg_get_multixact_stats() function in multixactfuncs.c. > - Fixed the misleading “ato

Re: make -C src/test/isolation failure in index-killtuples due to btree_gist

On Mon, Aug 18, 2025 at 11:38:02AM -0400, Tom Lane wrote: > Andres Freund writes: >> No, it makes absolutely no sense to test e.g. hash killtuples support in >> btree_gist. > > I think the complaint is that nothing has been done to ensure that > these modules have been installed. You created a n

Re: make -C src/test/isolation failure in index-killtuples due to btree_gist

On Mon, Aug 18, 2025 at 09:58:28AM -0400, Andres Freund wrote: > On 2025-08-18 08:57:13 +0900, Michael Paquier wrote: >> and it does not strike me as a good idea to begin doing that in the main >> isolation test suite, so perhaps the best thing to do here is just move this >> test to contrib/btree_

Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations

On Mon, Aug 18, 2025 at 03:10:42PM -0500, Sami Imseih wrote: > I agree, but I think it's time to start thinking about splitting > pg_stat_statements into multiple functions. This was recently > discussed [0] Yes, no idea for other people, but I'm putting a stop to new additions until we've split t

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

Hi, On Tue, Aug 19, 2025 at 7:14 AM Matheus Alcantara wrote: > > On Wed Aug 13, 2025 at 4:29 PM -03, Daniil Davydov wrote: > > > > What exactly do we mean by "active listener"? According to the source code, > > the active listener (as far as I understand) is the one who listens to at > > least >

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Wed Aug 13, 2025 at 4:29 PM -03, Daniil Davydov wrote: > Hi, > > On Mon, Aug 11, 2025 at 8:41 PM Matheus Alcantara > wrote: >> >> On Wed Aug 6, 2025 at 7:44 AM -03, Álvaro Herrera wrote: >> >> My questions: >> >> >> >> 1. Is it acceptable to drop notifications from the async queue if >> >> ther

Re: A few patches to clarify snapshot management

On Fri, Aug 15, 2025 at 02:12:03PM +0300, Heikki Linnakangas wrote: > On 10/08/2025 01:23, Noah Misch wrote: > > On Tue, Jan 07, 2025 at 11:55:00AM +0200, Heikki Linnakangas wrote: > > > On 07/01/2025 00:00, Andres Freund wrote: > > > > Hm. I'm not sure it's a good idea to forbid this. Couldn't the

Re: When deleting the plpgsql function, release the CachedPlan of the function

That's correct—this is a simple and blunt patch, and it fails to account for many factors. Initially, I wasn't even sure if this qualified as a distinct issue. Your solution is far more reasonable, and I will rethink the new implementation thoroughly based on your approach. Thanks, Zeng Man Th

Re: Improve LWLock tranche name visibility across backends

> I've been staring at the latest patch for a bit, and I'm a bit concerned > at how much complexity it adds. The complexity is the fact we have to track a dsa_pointer that points to an array of dsa_pointers that track the tranche names. We also do have to copy the array of dsa_pointers into a new

Re: Support getrandom() for pg_strong_random() source

On Mon, Aug 18, 2025 at 4:17 PM Michael Paquier wrote: > > On Mon, Aug 18, 2025 at 08:38:25AM -0700, Jacob Champion wrote: > > - Need for safety in virtualized environments > > - ...? > > Interesting. What do you mean by this point? Isolation of the > random computations on a VM/container basis

Re: Enhance Makefiles to rebuild objects on map file changes

Hi John, Let me explain the Makefile patch in this separate thread, as this is generic to all maps. Let’s not use gb18030 as an example, instead, using utf8_and_win. When any of the win-related map file changes, it suppose to automatically rebuild utf8_and_win.o. WITHOUT this patch, after I t

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Thu, Aug 14, 2025 at 4:44 PM shveta malik wrote: > > On Thu, Aug 14, 2025 at 7:28 AM Ajin Cherian wrote: > > > > > > Patch v6 attached. > > > > Thanks Ajin. Please find my comments: > > 1) > SyncReplicationSlots: > + remote_slots = fetch_or_refresh_remote_slots(wrconn, NIL); > + > + /* Retry u

Re: VM corruption on standby

On Tue, Aug 19, 2025 at 4:52 AM Tom Lane wrote: > But I'm of the opinion that proc_exit > is the wrong thing to use after seeing postmaster death, critical > section or no. We should assume that system integrity is already > compromised, and get out as fast as we can with as few side-effects > as

Re: VM corruption on standby

Hi! Thank you for putting attention to this. On Tue, 19 Aug 2025 at 10:32, Thomas Munro wrote: > > On Tue, Aug 19, 2025 at 4:52 AM Tom Lane wrote: > > But I'm of the opinion that proc_exit > > is the wrong thing to use after seeing postmaster death, critical > > section or no. We should assume

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

On Tue, 19 Aug 2025 at 01:34, Tom Lane wrote: > > David Rowley writes: > > I've purposefully left references to HASH_DEBUG in the "Original > > comments" section near the top of dynahash.c. That comment also > > references function names that no longer exist. > > Hm, there is actually no part of

Re: Logical Replication of sequences

On Mon, Aug 18, 2025 at 2:13 AM vignesh C wrote: > > On Sat, 16 Aug 2025 at 14:15, Masahiko Sawada wrote: > > > > As I understand it, the logical replication of sequences implemented > > by these patches shares the same user interface as table replication > > (utilizing CREATE PUBLICATION and CRE

Re: Support getrandom() for pg_strong_random() source

On Mon, Aug 18, 2025 at 08:38:25AM -0700, Jacob Champion wrote: > - Need for safety in virtualized environments > - ...? Interesting. What do you mean by this point? Isolation of the random computations on a VM/container basis even if these are originally from the same host? -- Michael signatu

Re: CREATE SCHEMA ... CREATE DOMAIN support

On Thu, Dec 12, 2024 at 1:08 AM Tom Lane wrote: > > The problem is not too awful right now, because of the very limited > set of object types that CREATE SCHEMA supports. The only case > I can think of offhand is a table referencing a view's rowtype, > for example > >create schema s1 >

Re: Memory leak of SMgrRelation object on standby

Hi~ Thanks for looking. > DropRelationFiles() is also called by FinishPreparedTransaction(). At > first I thought that might be a problem too, but looking a bit more > closely and trying it out... if a prepared transaction dropped a > table, then it called RelationDropStorage(), RelationCloseSmg

Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

On Tue, Aug 19, 2025 at 11:21:06AM +1200, David Rowley wrote: > Ok. I pushed it like that. Thanks for looking. Added a -DHASH_STATISTICS to batta, that runs only the master branch. -- Michael signature.asc Description: PGP signature

Re: psql: Count all table footer lines in pager setup

On 2025-08-17 17:19 +0200, Tom Lane wrote: > Erik Wienhold writes: > > On 2025-08-11 20:28 +0200, Greg Sabino Mullane wrote: > >> Patch looks good, applies and works. Needs a pgindent run: > > > Thanks for the review. Here's v2 with proper formatting. > > This appears to fix the problem it sets

Re: Remove useless pointer advance in StatsShmemInit()

On Mon, Aug 18, 2025 at 09:31:14AM +, Bertrand Drouvot wrote: > Yeah, that's probably just a matter of taste, but I also prefer keeping the > pointer over just doing: > > ctl->raw_dsa_area = (char *) ctl + MAXALIGN(sizeof(PgStat_ShmemControl)); Done as you have suggested. -- Michael signatu

Re: Logical Replication of sequences

On Mon, Aug 18, 2025 at 4:21 PM Masahiko Sawada wrote: > > For example, if a sequence is dropped > on the publisher, the subscriber would encounter synchronization > failures unless the DROP SEQUENCE is properly applied. This example is wrong. It seems DROP SEQUENCE works but we might have proble

Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

Kir Shatrov writes: Hi, > ## Unlocking Greater Extensions > > Extensions leveraging this metadata protocol could allow to build things with > very little overhead that are not possible > today: > > - Multi-tenant applications tracking per-query resource consumption (buffer > hits/misses, CPU/I

Re: Improve hash join's handling of tuples with null join keys

> On Aug 19, 2025, at 05:37, Tom Lane wrote: >> > > Yeah, we could make multi-batch PHJ do this differently from the other > cases, but I don't want to go there: too much complication and risk of > bugs for what is a purely hypothetical performance issue. Besides > which, if the join is large

Re: Re: When deleting the plpgsql function, release the CachedPlan of the function

That's correct??this is a simple and blunt patch, and it fails to account for many factors. Initially, I wasn't even sure if this qualified as a distinct issue. Your solution is far more reasonable, and I will rethink the new implementation thoroughly based on your approach. Thanks, Zeng Man

Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

Hi Michael, Ashutosh, Thanks a lot for taking the time to review this patch and share your thoughts. Here’s a short summary of what has changed in v5: - Added the new pg_get_multixact_stats() function in multixactfuncs.c. - Fixed the misleading “atomic read” comment in the accessor. - Clarified d

COPY TO: provide hint when WHERE clause is used

Hi, I saw a user wanted to restrict the rows copied by COPY TO using a WHERE clause, but ran into an error. As you know, COPY FROM supports WHERE, but COPY TO does not: =# copy t1 to stdout where i > 5; ERROR: WHERE clause not allowed with COPY TO LINE 1: copy t1 to stdout where i > 5;

  1   2   >