Re: amcheck support for BRIN indexes

On Tue, Jul 8, 2025 at 4:21 PM Tomas Vondra wrote: > > > > On 7/8/25 14:40, Arseniy Mukhin wrote: > > On Mon, Jul 7, 2025 at 3:21 PM Álvaro Herrera wrote: > >> > >> On 2025-Jul-07, Tomas Vondra wrote: > >> > >>> Alvaro, what's your opinion on the introduction of the new WITHIN_RANGE? > >>> I'd pr

Re: [V2] Adding new CRC32C implementation for IBM S390X

On Tue, Jul 8, 2025 at 6:46 PM Eduard Stefes wrote: > > Hi, > > here is V3 of the patch. Changes from V2: > > - removed IBM copyright > - removed GETAUXVAL check in favor of the already provided check > - moved runtime selection code from pg_crc32c_s390x_choose.c to > pg_crc32c_s390x.c and removed

Re: What is a typical precision of gettimeofday()?

On Tue, 2025-07-08 at 18:17 -0400, Tom Lane wrote: > One other thing that bothers me as I look at the output is > > Per loop time including overhead: 731.26 ns > > That's stated in a way that makes it sound like that is a > very solid number, when in fact it's just the average. > We see fro

Re: Improving and extending int128.h to more of numeric.c

On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed wrote: > 0001 is a trivial bug fix for the test code in src/tools/testint128.c > -- it was using "union" instead of "struct" for test128.hl, which > meant that it was only ever setting and checking half of each 128-bit > integer in the tests. Hi Dean,

Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach

On 7/8/25 18:06, Cédric Villemain wrote: On 7/8/25 03:55, Cédric Villemain wrote: Hi Andres, Hi, On 2025-07-05 07:09:00 +, Cédric Villemain wrote: In my work on more careful PostgreSQL resource management, I've come to the conclusion that we should avoid pushing policy too deeply

Re: Should TRUNCATE fire DDL triggers

On Tue, 2025-07-08 at 21:23 -0700, David G. Johnston wrote: > On Tuesday, July 8, 2025, Hari Krishna Sunder wrote: > > First of all, is TRUNCATE a DDL or a DML? This doc refers to it as a DDL, > > whereas other docs like this and this treat it as a DML, so which one is it? > > Neither…classificat

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

On Mon, Jun 30, 2025 at 4:26 PM Richard Guo wrote: > On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote: > > This patchset does not apply anymore due to 2c0ed86d3. Here is a new > > rebase. > This patchset does not apply anymore, due to 5069fef1c this time. > Here is a new rebase. Here is a new

Re: A recent message added to pg_upgade

On Wed, Jul 9, 2025 at 9:07 AM Dilip Kumar wrote: > > On Tue, Jul 8, 2025 at 5:24 PM Amit Kapila wrote: > > > > On Tue, Jul 8, 2025 at 4:49 PM Dilip Kumar wrote: > > > > > > On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila > > > wrote: > > > > > > > > On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar >

Re: POC: Parallel processing of indexes in autovacuum

Hi, On Tue, Jul 8, 2025 at 10:20 PM Matheus Alcantara wrote: > > On Sun Jul 6, 2025 at 5:00 AM -03, Daniil Davydov wrote: > > I will keep the 'max_worker_processes' limit, so autovacuum will not > > waste time initializing a parallel context if there is no chance that > > the request will succeed

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

Please find few more comments: 1) In pg_sync_replication_slots() doc, we have this: "Note that this function is primarily intended for testing and debugging purposes and should be used with caution. Additionally, this function cannot be executed if " We can get rid of this info as well and

RE: A assert failure when initdb with track_commit_timestamp=on

Dear Michael, > I'd suggest to keep them separate across multiple scripts, where they > hold meaning, as one failure may get hidden by the other. > track_commit_timestamp makes sense in the test module commit_ts, we > should select a second location for transaction_timeout if we keep it > at the e

Re: [PATCH] Add support for displaying database service in psql prompt

On Tue, Jul 08, 2025 at 05:41:32PM -0700, Noah Misch wrote: > I'd prefer not to get involved in decisions affecting only psql efficiency and > psql code cosmetics. Please make that decision without my input. Okay, I have used this more extensible routine then, planning to use it for the other pat

Re: Should TRUNCATE fire DDL triggers

On Tuesday, July 8, 2025, Hari Krishna Sunder wrote: > First of all, is TRUNCATE a DDL or a DML? This > doc refers to > it as a DDL, whereas other docs like this >

Should TRUNCATE fire DDL triggers

First of all, is TRUNCATE a DDL or a DML? This doc refers to it as a DDL, whereas other docs like this and this

Re: Can can I make an injection point wait occur no more than once?

On Tue, Jul 8, 2025 at 11:04 PM Noah Misch wrote: > > -backwards_scan_session: NOTICE: notice triggered for injection point > > lock-and-validate-new-lastcurrblkno > > +ERROR: could not find injection point lock-and-validate-left to wake up > > Agreed. Perhaps it's getting a different plan typ

Re: A recent message added to pg_upgade

On Tue, Jul 8, 2025 at 5:24 PM Amit Kapila wrote: > > On Tue, Jul 8, 2025 at 4:49 PM Dilip Kumar wrote: > > > > On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila wrote: > > > > > > On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote: > > > > > > > > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote: > > >

Re: Can can I make an injection point wait occur no more than once?

On Tue, Jul 08, 2025 at 11:21:20AM -0400, Peter Geoghegan wrote: > On Mon, Jul 7, 2025 at 9:53 PM Noah Misch wrote: > > If it continues to be a problem, consider sharing the patch that's behaving > > this way for you. > > Attached patch shows my current progress with the isolation test. Nothing

Re: Using failover slots for PG-non_PG logical replication

On Tue, Jul 8, 2025 at 7:29 PM Ashutosh Bapat wrote: > > On Tue, Jul 8, 2025 at 4:03 PM shveta malik wrote: > > > > On Mon, Jul 7, 2025 at 7:00 PM Ashutosh Bapat > > wrote: > > > > > > On Mon, Jul 7, 2025 at 9:53 AM shveta malik > > > wrote: > > > > > > > > Thanks for the patch. > > > > > > >

Re: A assert failure when initdb with track_commit_timestamp=on

On Wed, Jul 09, 2025 at 02:39:22AM +, Hayato Kuroda (Fujitsu) wrote: > +# Some GUCs like track_commit_timestamp cannot be set to non-default value in > +# bootstrap mode becasue they may cause crash. Ensure settings can be surely > +# ignored. > +command_ok( > + [ > + 'initd

RE: A assert failure when initdb with track_commit_timestamp=on

Dear Fujii-san, Andy, > Shouldn't we also add a TAP test to verify that initdb works correctly > with GUCs marked as GUC_NOT_IN_BOOTSTRAP? Another place we can put the test is 001_initdb.pl, like: ``` --- a/src/bin/initdb/t/001_initdb.pl +++ b/src/bin/initdb/t/001_initdb.pl @@ -331,4 +331,15 @@

Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE

On Mon, Jun 30, 2025 at 5:34 PM sundayjiang(蒋浩天) wrote: > > The purpose of this patch is to prevent replacing a function via `CREATE OR > REPLACE FUNCTION` with a new definition that is not marked as `IMMUTABLE`, if > the existing function is referenced by an index expression. > > Replacing such

Re: Adding wait events statistics

Hi, On 2025-06-30 13:36:12 +, Bertrand Drouvot wrote: > Wait events are useful to know what backends are waiting for when there is/was > a performance issue: for this we can sample pg_stat_activity at regular > intervals > and record historical data. That’s how it is commonly used. > > It cou

Re: Adding wait events statistics

On Tue, Jul 08, 2025 at 03:25:26PM +, Bertrand Drouvot wrote: > So, something like: > > ClassInfo LWLockClassInfo = { > .numberOfEvents = NB_LWLOCK_WAIT_EVENTS, > .pendingCounts = PendingWaitEventStats.lwlock_counts > }; > > and then the "global" one: > > WaitClassInfo *AllWaitClasse

Re: [PATCH] Add support for displaying database service in psql prompt

On Tue, Jul 08, 2025 at 08:52:08AM +0900, Michael Paquier wrote: > On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote: > > I think the choice to make there is whether to call PQconninfo() once per > > prompt emission or to cache the value, invalidating that cache e.g. once per > > SyncVaria

Re: Fix comment in btree_gist--1.8--1.9.sql

On Tue, Jul 08, 2025 at 04:49:30PM -0700, Paul Jungwirth wrote: > I noticed that the comment at the top of btree_gist--1.8--1.9.sql says it is > the 1.7--1.8 file. Here is a one-line patch to fix that. > > A related question: In the v18 release we are adding two upgrade files: > btree_gist--1.7--1

Re: Move the injection_points extension to contrib?

On Tue, Jul 08, 2025 at 05:50:59PM +0200, Antonin Houska wrote: > ok, I assume you mean that the requirement for ABI/API stability would make it > hard to include tests for fixes like [2] in minor releases. Thanks for > explanation. You can think about it the same way as we do for regress.so, for

Re: A assert failure when initdb with track_commit_timestamp=on

Fujii Masao writes: > Shouldn't we also add a TAP test to verify that initdb works correctly > with GUCs marked as GUC_NOT_IN_BOOTSTRAP? After revert 5a6c39b6d, the test case could be as simply as below: I also tested this change. Just FYI. modified src/test/modules/commit_ts/t/001_base.pl @@

Fix comment in btree_gist--1.8--1.9.sql

Hello Hackers, I noticed that the comment at the top of btree_gist--1.8--1.9.sql says it is the 1.7--1.8 file. Here is a one-line patch to fix that. A related question: In the v18 release we are adding two upgrade files: btree_gist--1.7--1.8.sql and btree_gist--1.8-1.9.sql. Why not collapse t

Re: mention unused_oids script in pg_proc.dat

On Tue, Jul 08, 2025 at 05:40:39PM +0300, Florents Tselai wrote: > On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut wrote: >>> + >>> +Below are some checklists for common scenarios. >>> + >>> +## Adding a New Built-in SQL Command >>> + >>> +1. Implement the function in C and place it in the approp

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

On Tue, Jul 08, 2025 at 12:58:26PM -0400, Burd, Greg wrote: > All that aside, I think you're right to tackle this one step at a > time and try not to boil too much of the ocean at once (the patch > set is already large enough). With that in mind I've read once or > twice over your changes and have

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

On Tue, Jul 08, 2025 at 09:31:29PM +0300, Nikita Malakhov wrote: > Michael, one more thing forgot to mention yesterday - > #define TOAST_EXTERNAL_INFO_SIZE (VARTAG_ONDISK_OID + 1) > static const toast_external_info > toast_external_infos[TOAST_EXTERNAL_INFO_SIZE] > VARTAG_ONDISK_OID historically ha

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

On Tue, Jul 08, 2025 at 08:54:33PM +0200, Hannu Krosing wrote: > I still think we should go with direct toast tid pointers in varlena > and not some kind of oid. > > It will remove the need for any oid management and also will be > many-many orders of magnitude faster for large tables (just 2x fast

Re: What is a typical precision of gettimeofday()?

Hannu Krosing writes: > On Tue, Jul 8, 2025 at 10:01 PM Tom Lane wrote: >> No, I think what's happening there is that we get to NUM_DIRECT before >> reaching the 99.99% mark. > Makes sense. > Should we change the header to something like > "Showing values covering up to 99.9900% of total observe

Re: Non-text mode for pg_dumpall

On Fri, Apr 04, 2025 at 04:11:05PM -0400, Andrew Dunstan wrote: > Thanks. I have pushed these now with a few further small tweaks. This drops all databases: pg_dumpall --clean -Fd -f /tmp/dump pg_restore -d template1 --globals-only /tmp/dump That didn't match my expectations given this help text

Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach

On 7/8/25 18:06, Cédric Villemain wrote: > > > > > > >> On 7/8/25 03:55, Cédric Villemain wrote: >>> Hi Andres, >>> Hi, On 2025-07-05 07:09:00 +, Cédric Villemain wrote: > In my work on more careful PostgreSQL resource management, I've come > to the > conclus

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

chunk_ On Tue, Jul 8, 2025 at 9:37 PM Álvaro Herrera wrote: > > On 2025-Jul-08, Hannu Krosing wrote: > > > I still think we should go with direct toast tid pointers in varlena > > and not some kind of oid. > > I think this can be made to work, as long as we stop seeing the toast > table just like

Re: IO worker crash in test_aio/002_io_workers

On Wed, Jul 9, 2025 at 8:45 AM Andres Freund wrote: > /* Got one. Clear idle flag. */ > io_worker_control->idle_worker_mask &= ~(UINT64_C(1) > << MyIoWorkerId); > > /* See if we can wake up some peers. */ >

Re: Horribly slow pg_upgrade performance with many Large Objects

On Sun, Jul 06, 2025 at 02:48:08PM +0200, Hannu Krosing wrote: > Did a quick check of the patch and it seems to work ok. Thanks for taking a look. > What do you think of the idea of not dumping pg_shdepend here, but > instead adding the required entries after loading > pg_largeobject_metadata bas

IO worker crash in test_aio/002_io_workers

Hi, Tomas off-list reported (he hit with a WIP patch applied) a crash he had been seeing in test_aio/002_io_workers. While I can't reproduce it as easily as he can, I hit it after a few hundred iterations of test_aio/002_io_workers. The one time I hit it I had forgotten to enable core dumps in t

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

Hi, Hannu, we have some thoughts on direct tids storage, it was some time ago and done by another developer, so I have to look. I'll share it as soon as I find it, if you are interested. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

Here is what I have staged for commit, which I'm planning to do tomorrow. -- nathan >From eae91e016509605630616a314a8ee2eaa1113b15 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Tue, 8 Jul 2025 14:52:36 -0500 Subject: [PATCH v6 1/1] Introduce pg_dsm_registry_allocations view. This commit a

Re: C11 / VS 2019

On 2025-07-08 Tu 3:45 PM, Tom Lane wrote: Andrew Dunstan writes: It's done and running. Testing before I re-enabled the animal it shows it was happy. In the no-good-deed-goes-unpunished department ... drongo is now spewing a boatload of these warnings: C:\\Program Files (x86)\\Windows Kits

Re: What is a typical precision of gettimeofday()?

Hannu Krosing writes: > On Tue, Jul 8, 2025 at 8:07 PM Tom Lane wrote: >> Even more interesting is what I got from an ancient PPC Macbook >> (mamba's host, running NetBSD): >> >> Testing timing overhead for 3 seconds. >> Per loop time including overhead: 731.26 ns >> ... >> Observed timing durat

Re: C11 / VS 2019

Andrew Dunstan writes: > It's done and running. Testing before I re-enabled the animal it shows > it was happy. In the no-good-deed-goes-unpunished department ... drongo is now spewing a boatload of these warnings: C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um\\winbase.h

Re: What is a typical precision of gettimeofday()?

On Tue, Jul 8, 2025 at 8:07 PM Tom Lane wrote: > > BTW, returning to the original topic of this thread: > > The new exact-delays table from pg_test_timing is really quite > informative. Maybe we should collect some of it in the PostgreSQL Wiki for easy reference ? I had some interesting results

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

On 2025-Jul-08, Hannu Krosing wrote: > I still think we should go with direct toast tid pointers in varlena > and not some kind of oid. I think this can be made to work, as long as we stop seeing the toast table just like a normal heap table containing normal tuples. A lot to reimplement though

Re: What is a typical precision of gettimeofday()?

Andrey Borodin writes: >> On 8 Jul 2025, at 23:07, Tom Lane wrote: >> The fact that the clock tick is about 40ns is extremely >> obvious in this presentation. > FWIW while working on UUID v7 Masahiko found that if we try to read real time > with clock_gettime(CLOCK_REALTIME,) measurement is tr

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

I still think we should go with direct toast tid pointers in varlena and not some kind of oid. It will remove the need for any oid management and also will be many-many orders of magnitude faster for large tables (just 2x faster for in-memory small tables) I plan to go over Michael's patch set he

Tab completion for large objects

Hi hackers, I noticed that psql's tab completion suggested TO immediately after GRANT ... ON LARGE OBJECT, and not after ON LARGE OBJECT . This is because LARGE OBJECT is the only two-word object type, so it thinks LARGE is the object type and OBJECT is the name. Attached are three patches that

Re: Logical replication prefetch

On 08/07/2025 2:51 pm, Amit Kapila wrote: On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote: It is possible to enforce parallel apply of short transactions using `debug_logical_replication_streaming` but then performance is ~2x times slower than in case of sequential apply by single wor

Re: Unnecessary delay in streaming replication due to replay lag

Hello Hackers, I recently had the opportunity to continue the effort originally led by a valued contributor. I’ve addressed most of the previously reported feedback and issues, and would like to share the updated patch with the community. IMHO starting WAL receiver eagerly offers significant adva

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

Hi! Greg, thanks for the interest in our work! Michael, one more thing forgot to mention yesterday - #define TOAST_EXTERNAL_INFO_SIZE (VARTAG_ONDISK_OID + 1) static const toast_external_info toast_external_infos[TOAST_EXTERNAL_INFO_SIZE] VARTAG_ONDISK_OID historically has a value of 18 and here w

Re: What is a typical precision of gettimeofday()?

> On 8 Jul 2025, at 23:07, Tom Lane wrote: > > The fact that the clock tick is about 40ns is extremely > obvious in this presentation. FWIW while working on UUID v7 Masahiko found that if we try to read real time with clock_gettime(CLOCK_REALTIME,) measurement is truncated to microseconds.

Re: What is a typical precision of gettimeofday()?

BTW, returning to the original topic of this thread: The new exact-delays table from pg_test_timing is really quite informative. For example, on my M4 Macbook: Observed timing durations up to 99.9900%: ns % of total running % count 0 62.212462.2124 118127987

Re: Remove redundant comment regarding RelationBuildRowSecurity in relcache.c

On Mon, 28 Apr 2025 at 16:02, Khan, Tanzeel wrote: > > A comment in relcache.c mentions that RelationBuildRowSecurity > adds a default-deny policy when no policy exists on table. This > does not seem to be the case. The default deny policy is added > later on, inside get_row_security_policies(). A

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

> On Jul 7, 2025, at 7:38 PM, Michael Paquier wrote: > > I have also pushed this v2 on this branch, so feel free to grab it if > that makes your life easier: > https://github.com/michaelpq/postgres/tree/toast_64bit_v2 > -- > Michael Thank you for spending time digging into this and for the we

Re: Inconsistent LSN format in pg_waldump output

On 2025-Jul-07, Japin Li wrote: > Thank you for pushing this patch. I noticed some other areas in the > documentation that could also use an update. Thanks! Pushed these fixes. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ Syntax error: function hell() needs

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

> On 8 Jul 2025, at 11:21 PM, Nathan Bossart wrote: > > On Tue, Jul 08, 2025 at 07:17:54PM +0800, Florents Tselai wrote: >> I can't see how it's possible to get the actual size for the dsa and dsh >> case, >> without attaching and then using, dsa_get_total_size on the attached dsa. >> And I d

Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach

On 7/8/25 03:55, Cédric Villemain wrote: Hi Andres, Hi, On 2025-07-05 07:09:00 +, Cédric Villemain wrote: In my work on more careful PostgreSQL resource management, I've come to the conclusion that we should avoid pushing policy too deeply into the PostgreSQL core itself. Therefor

Re: Move the injection_points extension to contrib?

Hayato Kuroda (Fujitsu) wrote: > Dear Antonin, > > > Having the extension in contrib would be useful in cases a 3rd party > > extension > > uses injection points in its regression tests. In particular, it's more > > practical for CI to install the "injection_points" extension by installing > >

Re: What is a typical precision of gettimeofday()?

Hannu Krosing writes: > On Mon, Jul 7, 2025 at 11:38 PM Tom Lane wrote: >> What do you think of instead specifying the limit as the maximum >> running-percentage to print, with a default of say 99.99%? That >> gives me results like > I agree that percentage covered is a much better metric indee

Re: Adding wait events statistics

Hi, On Tue, Jul 08, 2025 at 04:46:28AM +, Bertrand Drouvot wrote: > On Tue, Jul 08, 2025 at 09:36:53AM +0900, Michael Paquier wrote: > > Yes, you may need some level of meta-data generated for the wait > > classes generated when the perl script generating this data is run. > > It would be nice

Re: Can can I make an injection point wait occur no more than once?

On Mon, Jul 7, 2025 at 9:53 PM Noah Misch wrote: > If it continues to be a problem, consider sharing the patch that's behaving > this way for you. Attached patch shows my current progress with the isolation test. I also attach diff output of the FreeBSD failures. Notice that the line "backwards_

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

On Tue, Jul 08, 2025 at 07:17:54PM +0800, Florents Tselai wrote: > I can't see how it's possible to get the actual size for the dsa and dsh case, > without attaching and then using, dsa_get_total_size on the attached dsa. > And I don't think we wanna do that. > > Instead maybe we can just report N

Re: POC: Parallel processing of indexes in autovacuum

On Sun Jul 6, 2025 at 5:00 AM -03, Daniil Davydov wrote: >> The "autovacuum_max_parallel_workers" declared on guc_tables.c mention >> that is capped by "max_worker_process": >> + { >> + {"autovacuum_max_parallel_workers", PGC_SIGHUP, >> VACUUM_AUTOVACUUM, >> +

Re: Add os_page_num to pg_buffercache

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Bertrand, Just tried out your patch, nice work, thought

Re: mention unused_oids script in pg_proc.dat

On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut wrote: > On 24.05.25 12:34, Florents Tselai wrote: > > > > > >> On 24 May 2025, at 12:24 PM, Álvaro Herrera > wrote: > >> > >> On 2025-May-24, Florents Tselai wrote: > >> > >>> I aggree with having more READMEs around the src tree. > >>> It’s true

Re: Small optimization with expanding dynamic hash table

> One thing to note is that in this scenario, there is no safeguard if the hashvalue is 0x111 and new_bucket is 0x110. But the hash table is already corrupted if the hashvalue 0x111 in old_bucket 0x010, all hashvalue in old_bucket should have: hashvalue & low_mask == old_bucket's no. -- Regar

Re: array_random

Hi, > it seems not trivial to wrap up all the generated random values into a > specific > multi-dimensional array (more than 2 dimensions). > for example, say we generated 24 random values and wanted to arrange them > into a > 3-dimensional array with shape [4, 3, 2]. > we can easily use: > SELE

Re: Using failover slots for PG-non_PG logical replication

On Tue, Jul 8, 2025 at 4:03 PM shveta malik wrote: > > On Mon, Jul 7, 2025 at 7:00 PM Ashutosh Bapat > wrote: > > > > On Mon, Jul 7, 2025 at 9:53 AM shveta malik wrote: > > > > > > Thanks for the patch. > > > > > > > I couldn't figure out whether the query on primary to fetch all the > > > > slo

Re: [PATCH] Support for basic ALTER TABLE progress reporting.

hi. within ATRewriteTable we have: pgstat_progress_update_param(PROGRESS_CLUSTER_TOTAL_HEAP_BLKS, RelationGetNumberOfBlocks(oldrel)); pgstat_progress_update_param(PROGRESS_CLUSTER_TOTAL_HEAP_BLKS, heapScan->rs_nblocks); PROGRESS_CLUSTER_TOTAL_HE

Re: amcheck support for BRIN indexes

On 7/8/25 14:40, Arseniy Mukhin wrote: > On Mon, Jul 7, 2025 at 3:21 PM Álvaro Herrera wrote: >> >> On 2025-Jul-07, Tomas Vondra wrote: >> >>> Alvaro, what's your opinion on the introduction of the new WITHIN_RANGE? >>> I'd probably try to do this using the regular consistent function: >>> >>>

Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment

On 07.07.2025 16:49, Andrei Lepikhov wrote: Exposing internal information about the estimation of the number of groups in the Memoise node, shouldn't we do the same in even more vague cases, such as IncrementalSort? For example, in [1] (see its attachment), I observe that IncrementalSort is co

Re: Adding basic NUMA awareness

Hi, On 2025-07-08 14:27:12 +0200, Tomas Vondra wrote: > On 7/8/25 05:04, Andres Freund wrote: > > On 2025-07-04 13:05:05 +0200, Jakub Wartak wrote: > > The reason it would be advantageous to put something like the procarray onto > > smaller pages is that otherwise the entire procarray (unless part

Re: amcheck support for BRIN indexes

On Mon, Jul 7, 2025 at 3:21 PM Álvaro Herrera wrote: > > On 2025-Jul-07, Tomas Vondra wrote: > > > Alvaro, what's your opinion on the introduction of the new WITHIN_RANGE? > > I'd probably try to do this using the regular consistent function: > > > > (a) we don't need to add stuff to all BRIN opcl

Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach

On 7/8/25 03:55, Cédric Villemain wrote: > Hi Andres, > >> Hi, >> >> On 2025-07-05 07:09:00 +, Cédric Villemain wrote: >>> In my work on more careful PostgreSQL resource management, I've come >>> to the >>> conclusion that we should avoid pushing policy too deeply into the >>> PostgreSQL core

Re: Adding basic NUMA awareness

On 7/8/25 05:04, Andres Freund wrote: > Hi, > > On 2025-07-04 13:05:05 +0200, Jakub Wartak wrote: >> On Tue, Jul 1, 2025 at 9:07 PM Tomas Vondra wrote: >>> I don't think the splitting would actually make some things simpler, or >>> maybe more flexible - in particular, it'd allow us to enable huge

Re: A recent message added to pg_upgade

On Tue, Jul 8, 2025 at 4:49 PM Dilip Kumar wrote: > > On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila wrote: > > > > On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote: > > > > > > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote: > > > > > > > > > > > There's a bigger picture here, though. The fundam

Re: Logical replication prefetch

On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote: > > There is well known Postgres problem that logical replication subscriber > can not caught-up with publisher just because LR changes are applied by > single worker and at publisher changes are made by > multiple concurrent backends. The

Re: [V2] Adding new CRC32C implementation for IBM S390X

Hi, here is V3 of the patch. Changes from V2: - removed IBM copyright - removed GETAUXVAL check in favor of the already provided check - moved runtime selection code from pg_crc32c_s390x_choose.c to pg_crc32c_s390x.c and removed _choose.c file - removed the config time compiler check and let the

Re: A assert failure when initdb with track_commit_timestamp=on

On Sat, Jul 05, 2025 at 02:00:07PM -0400, Tom Lane wrote: > Here's a fleshed-out implementation of Hayato-san's idea. I've > not done anything about reverting 5a6c39b6d, nor have I done any > checks to see if there are other GUCs we ought to mark similarly. > (But at this point I'd be prepared to

Re: A recent message added to pg_upgade

On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila wrote: > > On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote: > > > > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote: > > > > > > > > There's a bigger picture here, though. The fundamental thing that > > > I find wrong with the current code is that kno

Re: like pg_shmem_allocations, but fine-grained for DSM registry ?

> On 25 Jun 2025, at 4:33 AM, Nathan Bossart wrote: > > for DSAs and dshash tables, we probably want to use dsa_get_total_size() > for the "size" column. > The thing is that dsa_get_total_size expects an already attached dsa. I can't see how it's possible to get the actual size for the dsa a

Re: Small optimization with expanding dynamic hash table

Hi, Yes, for example: >> >> low_mask: 0x011, high_mask: 0x111, old_bucket: 0x010, new_bucket: 0x110 >> >> The old_bucket's hash value like 0x***010 or 0x***110, the later is in >> the old_bucket is because we didn't have new_bucket before, so only hash >> value like 0x***110 needs relocation: hash

Re: 024_add_drop_pub.pl might fail due to deadlock

On Mon, Jul 7, 2025 at 8:15 PM Ajin Cherian wrote: > > On Sun, Jul 6, 2025 at 2:00 AM Alexander Lakhin wrote: > > > > --- a/src/backend/replication/logical/origin.c > > +++ b/src/backend/replication/logical/origin.c > > @@ -428,6 +428,7 @@ replorigin_drop_by_name(const char *name, bool > > missi

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

On Sun, Jul 6, 2025 at 8:33 PM Masahiko Sawada wrote: > > On Thu, Jul 3, 2025 at 3:32 PM shveta malik wrote: > > > > On Wed, Jul 2, 2025 at 9:46 PM Masahiko Sawada > > wrote: > > > > > > On Wed, Jun 18, 2025 at 1:07 PM shveta malik > > > wrote: > > > > > > > > On Wed, Jun 18, 2025 at 6:06 AM

Re: Using failover slots for PG-non_PG logical replication

On Mon, Jul 7, 2025 at 7:00 PM Ashutosh Bapat wrote: > > On Mon, Jul 7, 2025 at 9:53 AM shveta malik wrote: > > > > Thanks for the patch. > > > > > I couldn't figure out whether the query on primary to fetch all the > > > slots to be synchronized should filter based on invalidation_reason > > > a

Re: Expand applicability of aggregate's sortop optimization

On Tue, 4 Mar 2025 at 15:26, Andrei Lepikhov wrote: > > Rebase on current master. FYI, as this is a significantly different patch than the one I started this thread with, I'm closing my CF entry. Feel free to open a new one for your patch. Kind regards, Matthias van de Meent

Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root

On Tue, Jul 8, 2025 at 11:53 AM Mikhail Kharitonov wrote: > > Hi all, > > I’m sending v2 of the patch. This is a clean rebase onto current master > (commit a27893df45e) and a squash of the fix together with the TAP > test into a single patch file. > > I would appreciate your thoughts and comments

Re: Explicitly enable meson features in CI

Hi, On Wed, 2 Jul 2025 at 10:22, Nazir Bilal Yavuz wrote: > > Also, libcurl is disabled in the OpenBSD CI task until the fix in this > thread [1] is committed. This fix is committed in 7376e60854 so libcurl is enabled for OpenBSD in v4. -- Regards, Nazir Bilal Yavuz Microsoft From 4cbdc65f0f47

Re: A recent message added to pg_upgade

On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote: > > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote: > > > > > There's a bigger picture here, though. The fundamental thing that > > I find wrong with the current code is that knowledge of and > > responsibility for this max_slot_wal_keep_size ha

Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root

Hi all, I’m sending v2 of the patch. This is a clean rebase onto current master (commit a27893df45e) and a squash of the fix together with the TAP test into a single patch file. I would appreciate your thoughts and comments on the current problem. Thank you! -- Best regards, Mikhail Kharitonov

Re: Fix replica identity checks for MERGE command on published table.

On Mon, 7 Jul 2025 at 18:17, Dean Rasheed wrote: > > This makes me wonder though, does INSERT ... ON CONFLICT DO UPDATE > have the same problem as MERGE? > Answering my own question, INSERT ... ON CONFLICT DO UPDATE does have the same problem as MERGE. To reproduce the error, all you need to do i

Re: Small optimization with expanding dynamic hash table

Hi, Yes, for example: > > low_mask: 0x011, high_mask: 0x111, old_bucket: 0x010, new_bucket: 0x110 > > The old_bucket's hash value like 0x***010 or 0x***110, the later is in the > old_bucket is because we didn't have new_bucket before, so only hash value > like 0x***110 needs relocation: hashvalue

Re: Elimination of the repetitive code at the SLRU bootstrap functions.

Álvaro, thank you for pushing, attention and final editing of the patch! I got your recommendations and requirements. I will take them into account at a next patch. Andrey, Alexander thank you for your proposals, attention, advice, and review! Best regards, Evgeny Voropaev, Tantor Labs, LLC.

Re: A assert failure when initdb with track_commit_timestamp=on

On 2025/07/06 3:00, Tom Lane wrote: I wrote: Fujii Masao writes: Or GUC ignore_system_indexes also should be treated in the same way as transaction_timeout? Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap too. I've not done any research about what other GUCs can brea

Re: Small optimization with expanding dynamic hash table

> Will this still work if new_bucket is not equal to hctl->low_mask + 1?Yes, for example: low_mask: 0x011, high_mask: 0x111, old_bucket: 0x010, new_bucket: 0x110 The old_bucket's hash value like 0x***010 or 0x***110, the later is in the old_bucket is because we didn't have new_bucket before,

Re: array_random

On Sat, Jul 5, 2025 at 3:32 PM Vik Fearing wrote: > > On 30/06/2025 17:04, jian he wrote: > > reasons for adding array_random is: > 1. This is better than array_fill. This can fill random and constant > values (random, min and max the same). > 2. Building a multi-dimensional PL/pgSQL function equ

Re: A recent message added to pg_upgade

On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote: > > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote: > > > > Dilip Kumar writes: > > >> IMHO we can just query the 'max_slot_wal_keep_size' after > > >> start_postmaster() and check what is the final resultant value. So now > > >> we will only th