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

On Wed, Jun 11, 2025 at 2:31 AM Masahiko Sawada wrote: > > I think it's the user's responsibility to keep at least one logical > slot. It seems that setting wal_level to 'logical' would be the most > reliable solution for this case. We might want to provide a way to > keep 'logical' WAL level some

Re: [PATCH] Add an ldflags_sl meson build option

I have a Bazel toolchain that sets different linker flags for exe/shared lib. I wanted to build postgresql shared libs with meson using the same toolchain flags that I build all my other 3rd party deps in Bazel. Currently for postgresql builds, we set LDFLAGS to the Bazel toolchain executable f

Re: Replication slot is not able to sync up

On Mon, Jun 16, 2025 at 9:27 AM shveta malik wrote: > > Thanks Peter and Amit for feedback. I have updated the patch. > + When slot-synchronization setup is done as recommended, and + slot-synchronization is performed the very first time either automatically + or by + pg_sync_re

Re: pg_upgrade fails with an error "object doesn't exist"

> On 17 Jun 2025, at 04:58, Tom Lane wrote: > There are enough moving parts in that area > already that I'm not eager to add more constraints to what pg_dump > needs to do. Agreed. I we were to do anything I think a check in pg_upgrade would be more appropriate than altering pg_dump (but I'm no

Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)

On 2025/06/17 4:48, Ranier Vilela wrote: Hi. In the function *estimate_path_cost_size* the parameter fpextra can be NULL. Yes. It is necessary to always check its validity, as is already done in other parts of the source. patch attached. adjust_foreign_

Re: wrong comments in rewriteTargetListIU

On 10.04.25 11:46, Amit Langote wrote: Hi, On Thu, Apr 10, 2025 at 5:58 PM jian he wrote: hi. in function, rewriteTargetListIU we have: for (attrno = 1; attrno <= numattrs; attrno++) { /* * Can only insert DEFAULT into generated columns, regardless of

Re: pg_upgrade fails with an error "object doesn't exist"

Vaibhav Dalvi writes: > Should we at least restrict dumping privileges for user objects inside > pg_catalog to avoid pg_upgrade failure? You haven't made a credible case for us to add any complexity in this area. Anybody messing with pg_catalog is living very much in "if you break it, you get to

Re: confusing message in check_tuple

On 12.06.25 08:26, jian he wrote: in contrib/amcheck/verify_heapam.c, check_tuple report_corruption(ctx, psprintf("number of attributes %u exceeds maximum expected for table %u", ctx->natts,

Re: fix: propagate M4 env variable to flex subprocess

On 28.05.25 20:42, J. Javier Maestro wrote: On Wed, May 28, 2025 at 6:08 PM Andres Freund > wrote: Hi, On 2025-05-17 23:32:24 -0400, J. Javier Maestro wrote: > On Tue, May 13, 2025 at 11:54 AM Andres Freund mailto:and...@anarazel.de>> wrote: > >

Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

Ashutosh Bapat writes: > On Mon, Jun 16, 2025 at 6:48 PM Jelte Fennema-Nio wrote: >> The new PG19 development cycle is starting soon. So that seemed like a >> good excuse to make some big improvements to the commitfest app. My >> plan is to deploy these changes on the 30th of June. > Coinciding

RE: Improve CRC32C performance on SSE4.2

Let me know if this fixes the failure. This is technically not a compiler bug. > -Original Message- > From: Devulapalli, Raghuveer > Sent: Monday, June 16, 2025 4:53 PM > To: Andy Fan > Cc: Nathan Bossart ; John Naylor > ; Jesper Pedersen ; > Tomas Vondra ; pgsql-hackers@lists.postgresql

Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

On Mon, Jun 16, 2025 at 6:48 PM Jelte Fennema-Nio wrote: > > The new PG19 development cycle is starting soon. So that seemed like a > good excuse to make some big improvements to the commitfest app. My > plan is to deploy these changes on the 30th of June. So that we can > start the new cycle fres

RE: Suggestion to add --continue-client-on-abort option to pgbench

Dear Nagata-san, > > > 2. The exit-on-abort option and continue-on-error option are mutually > exclusive. > > > Therefore, I've updated the patch to throw a FATAL error when two options > are > > > set simultaneously. Corresponding explanation was also added. > > I don't think that's right since

Re: Allow pg_dump --statistics-only to dump foreign table statistics?

On 2025/06/17 7:44, Corey Huinker wrote: The proposed patch [0] adds RELKIND_FOREIGN_TABLE to this list.  That appears to be the only missing relation kind that ANALYZE handles. [0] https://postgr.es/m/attachment/177608/v1-0001-pg_dump-Allow-pg_dump-to-dump-the-statistics-for-.pat

Re: Allow pg_dump --statistics-only to dump foreign table statistics?

On 2025/06/14 7:31, Nathan Bossart wrote: On Fri, Jun 13, 2025 at 04:19:26PM +0900, Fujii Masao wrote: I noticed that pg_restore_relation|attribute_stats() can restore statistics for foreign tables, but pg_dump --statistics-only doesn't include them. Is there a reason why pg_dump skips statis

RE: pg_recvlogical cannot create slots with failover=true

Dear Amit, Sawada, Peter, > > > I wonder if the option name --failover is ideal. To me, it sounds like > > > an action "do a failover!". Also consider that pg_recvlogical has other > > > action options such as --start and --create-slot, so it sounds a bit > > > like those. > > > > Fair point. >

回复: 回复: 回复: Fix potential overflow risks from wcscpy and sprintf

Thank you, Tom. You’re absolutely right―this change is not necessary. I’ve updated the patch accordingly. Best regards, Haibo 发件人: Tom Lane 发送时间: 2025年6月16日 12:46 收件人: Yan Haibo 抄送: Peter Eisentraut ; pgsql-hackers@lists.postgresql.org 主题: Re: 回复: 回复: Fix pote

Re: BackendKeyData is mandatory?

On Monday, June 16, 2025, Tatsuo Ishii wrote: > > My question is, BackendKeyData is mandatory or not. Currently > Pgpool-II raises a fatal error if BackendKeyData is not sent before > ReadyForQuery arrives. This is because without the message, frontend > cannot send a CancelRequest message later

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

Hi Alexander, While tracking buildfarm for one of other commits, I noticed this failure: TRAP: failed Assert("s->data.restart_lsn >= s->last_saved_restart_lsn"), File: "../pgsql/src/backend/replication/slot.c", Line: 1813, PID: 3945797 postgres: standby: checkpointer (ExceptionalCondition+0x83) [0

Re: BackendKeyData is mandatory?

Tatsuo Ishii writes: > In the Frontend/Backend protocol, it is explained that after > successful authentication following messages can be sent from backend > to frontend[1]: > BackendKeyData > ParameterStatus > ReadyForQuery > ErrorResponse > NoticeResponse > My question is, BackendKeyData is ma

Re: pg_upgrade fails with an error "object doesn't exist"

Hi Tom, Should we at least restrict dumping privileges for user objects inside pg_catalog to avoid pg_upgrade failure? Regards, Vaibhav On Mon, Jun 16, 2025 at 7:11 PM Tom Lane wrote: > Daniel Gustafsson writes: > > On 16 Jun 2025, at 09:29, Vaibhav Dalvi > wrote: > >> Why can't we strictly

BackendKeyData is mandatory?

In the Frontend/Backend protocol, it is explained that after successful authentication following messages can be sent from backend to frontend[1]: BackendKeyData ParameterStatus ReadyForQuery ErrorResponse NoticeResponse My question is, BackendKeyData is mandatory or not. Currently Pgpool-II rais

Re: pg_dump --with-* options

On 2025/06/17 9:58, Nathan Bossart wrote: On Mon, Jun 16, 2025 at 07:09:17PM -0400, Tom Lane wrote: I find myself increasingly persuaded by Corey's point of view ... +1 Can you clarify how using on-by-default would simplify things? I'm not sure it actually makes the options simpler. Rega

Re: pg_dump --with-* options

On 2025/06/17 4:35, Corey Huinker wrote: I noticed that --statistics (i.e., the current --with-statistics) causes statistics to be dumped even when used with --data-only or --schema-only. So, as far as I understand, here are the possible combinations of dump targets and options

Re: pg_dump --with-* options

On Mon, Jun 16, 2025 at 07:09:17PM -0400, Tom Lane wrote: > I find myself increasingly persuaded by Corey's point of view ... +1 -- nathan

Re: Make COPY format extendable: Extract COPY TO format implementations

On Tue, Jun 17, 2025 at 08:50:37AM +0900, Sutou Kouhei wrote: > OK. I'll implement the initial version with this > design. (Allocating IDs local not shared.) Sounds good to me. Thanks Sutou-san! -- Michael signature.asc Description: PGP signature

Re: Non-reproducible AIO failure

Konstantin Knizhnik writes: > On 16/06/2025 6:11 pm, Andres Freund wrote: >> I unfortunately can't repro this issue so far. > But unfortunately it means that the problem is not fixed. FWIW, I get similar results to Andres' on a Mac Mini M4 Pro using MacPorts' current compiler release (clang vers

Re: [BUG?] check_exclusion_or_unique_constraint false negative

Rebased. v8-0001-Add-an-isolation-test-to-reproduce-a-dirty-snapsh.patch Description: Binary data v8-0002-Fix-btree-index-scan-concurrency-issues-with-dirt.patch Description: Binary data

RE: Improve CRC32C performance on SSE4.2

Great catch! From the intrinsic manual: Cast vector of type __m128i to type __m512i; the upper 384 bits of the result are undefined. Replacing that with _mm512_zextsi128_si512 fixes the problem. > -Original Message- > From: Nathan Bossart > Sent: Monday, June 16, 2025 3:14 PM > To: D

RE: Improve CRC32C performance on SSE4.2

> Just be curious, what kind of optimization (like what -O2 does) could mask > this > issue? >= -O1. Only -O0 shows this problem. Raghuveer

Re: Improve CRC32C performance on SSE4.2

"Devulapalli, Raghuveer" writes: > Great catch! From the intrinsic manual: > > Cast vector of type __m128i to type __m512i; the upper 384 bits of the > result are undefined. Just be curious, what kind of optimization (like what -O2 does) could mask this issue? > Replacing that with _mm512_zext

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Thu, 12 Jun 2025 10:00:12 -0700, Masahiko Sawada wrote: >> So, my opinion is to rely on _PG_init(), with a shared ID if you want >> to expose the method used somewhere for monitoring tools. You could >> as

Re: Fix slot synchronization with two_phase decoding enabled

On Wed, Jun 11, 2025 at 9:50 PM shveta malik wrote: > > On Wed, Jun 11, 2025 at 11:31 PM Masahiko Sawada > wrote: > > > > > BTW have we addressed the point Amit mentioned before[1]? > > > > > The one more combination to consider is when someone takes a dump of > > > an older version and loads it

Re: Returning nbtree posting list TIDs in DESC order during backwards scans

On Mon, Jun 16, 2025 at 12:46 PM Peter Geoghegan wrote: > Making this change in _bt_readpage creates a problem in _bt_killitems: > it currently expects posting list TIDs in ascending order (the loop > invariant relies on that), which is why the deduplication patch didn't > just do things like this

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hello, Sergey! > I think it's to avoid duplicate errors when adding tuples from STIP to the > main index, > but couldn't we just suppress that error during validation and skip the new > tuple insertion if it already exists? In some cases, it is not possible: – Some index types (GiST, GIN, BRIN)

Re: pg_dump --with-* options

Jeff Davis writes: > Does it make any sense to be off by default in 18 and on in some later > release? Probably not, especially if part of the argument for on-by-default is to allow simplification of the switch set. We don't get that benefit if we ship with off-by-default, and we won't be able t

Re: pg_dump --with-* options

On Mon, 2025-06-16 at 16:09 -0500, Nathan Bossart wrote: > So perhaps there's not as strong of a > consensus as we thought.  Maybe we should ask for any new/updated > votes. Does it make any sense to be off by default in 18 and on in some later release? Regards Jeff Davis

Re: Make tuple deformation faster

On Sat, 14 Jun 2025 at 19:04, David Rowley wrote: > I propose I just push the fix_idea.patch and leave it at that for v18. > > Does anyone have any other ideas? I've now pushed that as a fix. David

Re: No error checking when reading from file using zstd in pg_dump

> On 16 Jun 2025, at 21:45, Tomas Vondra wrote: > Regarding the Z_NULL, I believe it has always been ignored like this, at > least since 9.1. The code simply returns what gzgets() returns, and then > compares that to NULL, etc. Is there there's a better way to deal with > Z_NULL? I suppose we cou

Re: Allow pg_dump --statistics-only to dump foreign table statistics?

> > The proposed patch [0] adds RELKIND_FOREIGN_TABLE to this list. That > appears to be the only missing relation kind that ANALYZE handles. > > [0] > https://postgr.es/m/attachment/177608/v1-0001-pg_dump-Allow-pg_dump-to-dump-the-statistics-for-.patch > > Thanks for pointing it out, a little dis

Re: Improve CRC32C performance on SSE4.2

On Mon, Jun 16, 2025 at 06:31:11PM +, Devulapalli, Raghuveer wrote: > Attached is a simple reproducer. It passes with clang v16 -O0, but fails > with 17 and 18 only when built with -O0.. I've just started looking into this, but the difference in code generated for _mm512_castsi128_si512() betw

Re: Per-role disabling of LEAKPROOF requirements for row-level security?

On Mon, Jun 16, 2025 at 01:36:20PM -0400, Tom Lane wrote: > There might be a genuine hazard if something thinks it can substitute > use of enum_cmp for enum_eq, as indeed would happen in e.g. mergejoin. Hm. Wouldn't that be a mergejoin bug? I guess I'm not sure how to reconcile the leakproof cri

Re: Allow pg_dump --statistics-only to dump foreign table statistics?

On Mon, Jun 16, 2025 at 03:39:07PM -0400, Corey Huinker wrote: > If we aren't exporting stats for foreign tables then that is an oversight, > the intention always was to fetch all available statistics for all > relations. I can't offhand think of where we even have the option to > exclude them. ge

Re: pg_dump --with-* options

On Mon, Jun 16, 2025 at 03:35:48PM -0400, Corey Huinker wrote: > I think this is the exact sort of confusion caused by having two of the > three types default to on in all circumstances, and one default to off in > one special circumstance. I revisited the main thread to see how folks voted. Ther

Re: No error checking when reading from file using zstd in pg_dump

Tomas Vondra writes: > For a moment I was worried about breaking ABI when fixing this in the > backbranches, but I guess that's not an issue for tools like pg_dump. Yeah, I think it'd be okay to change compress_io.h APIs in the back branches; it's hard to see how anything outside pg_dump+pg_resto

Re: Amcheck verification of GiST and GIN

On 6/16/25 21:09, Arseniy Mukhin wrote: > On Mon, Jun 16, 2025 at 6:58 PM Tomas Vondra wrote: >> >> Thanks. >> >> I went through the patches, polished the commit messages and did some >> minor tweaks in patch 0002 (to make the variable names a bit more >> consistent, and reduce the scope a little

Re: No error checking when reading from file using zstd in pg_dump

On 6/16/25 19:56, Tom Lane wrote: > ... > > After looking around a bit more I realized that this API is a complete > disaster: it's not only bug-prone, but there are actual bugs in > multiple callers, eg _ReadBuf() totally fails to detect early EOF as > it intends to. We need to fix it, not slap

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Thank you for the information. Tomorrow, I will also run a few tests to measure the time required to collect tids from the index; however, since I do not work with vanilla postgres, the results may vary. If the results indicate that this procedure is time-consuming, I maybe will develop an additio

RE: Improve CRC32C performance on SSE4.2

Attached is a simple reproducer. It passes with clang v16 -O0, but fails with 17 and 18 only when built with -O0. Build command: clang main.c -O0 Hope this helps. Raghuveer > -Original Message- > From: John Naylor > Sent: Sunday, June 15, 2025 7:39 PM > To: Andy Fan > Cc: Jesper Ped

Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)

Hi. In the function *estimate_path_cost_size* the parameter fpextra can be NULL. It is necessary to always check its validity, as is already done in other parts of the source. patch attached. Best regards, Ranier Vilela fix-possible-dereference-null-pointer-postgres_fdw.patch Description: Bi

Re: 回复: 回复: Fix potential overflow risks from wcscpy and sprintf

Yan Haibo writes: > Regarding the use of wcsncpy with LOCALE_NAME_MAX_LENGTH - 1, it is a > precaution in case the input string is not null-terminated. I don't think it's a "precaution". I think it's introducing a real bug (that is, failure on a locale name of exactly the max allowed length) to

Re: No error checking when reading from file using zstd in pg_dump

On 6/16/25 17:41, Daniel Gustafsson wrote: >> On 16 Jun 2025, at 16:20, Tom Lane wrote: >> >> Daniel Gustafsson writes: On 16 Jun 2025, at 15:56, Tom Lane wrote: I've not checked to see what the other users of this API do, but if they're all like this then we need to fix that comm

Re: pg_dump --with-* options

> > I noticed that --statistics (i.e., the current --with-statistics) causes > statistics to be dumped even when used with --data-only or --schema-only. > So, as far as I understand, here are the possible combinations of dump > targets and options: > Those should also be mutually exclusive, and I'

Avoid possible dereference null pointer (src/backend/utils/cache/relcache.c)

Hi. The function *ScanPgRelation* can return a invalid tuple. It is necessary to check the function's return, as is already done in other parts of the source. patch attached. Best regards, Ranier Vilela fix-possible-dereference-null-pointer-relcache.patch Description: Binary data

Re: Allow pg_dump --statistics-only to dump foreign table statistics?

> > I skimmed through the main thread for the feature [0] (which seems to be so > long that it sometimes doesn't load completely), and I didn't see anything > directly related to the topic. There was some discussion about importing > foreign relation stats with the new functions instead of remote

回复: Fix potential overflow risks from wcscpy and sprintf

Thank you. Peter. It seems the patch may have been lost during our earlier communication, so I’ve reattached it here. I hope it comes through correctly this time. Best regards, Haibo 发件人: Peter Eisentraut 发送时间: 2025年6月11日 00:43 收件人: Yan Haibo ; pgsql-hackers@list

回复: 回复: Fix potential overflow risks from wcscpy and sprintf

Thank you. Tom. I agree that fixing the sprintf usage is not well-timed at the moment, so I’ve removed that change. Regarding the use of wcsncpy with LOCALE_NAME_MAX_LENGTH - 1, it is a precaution in case the input string is not null-terminated. Thanks again, Haibo __

Re: pglogical3 : support

On Mon, Jun 16, 2025 at 02:50:18PM +0530, Amit Kapila wrote: > On Sat, Jun 14, 2025 at 2:05 PM Perumal Raj wrote: > > > > Hi Team, > > > > I am looking to upgrade pg17 with near zero downtime using logical > > replication(master <-> master) . The current pglogical2 ( open) has some > > limitati

Re: Amcheck verification of GiST and GIN

On Mon, Jun 16, 2025 at 6:58 PM Tomas Vondra wrote: > > Thanks. > > I went through the patches, polished the commit messages and did some > minor tweaks in patch 0002 (to make the variable names a bit more > consistent, and reduce the scope a little bit). I left it as a separate > patch to make th

Re: 回复: Fix potential overflow risks from wcscpy and sprintf

Yan Haibo writes: > Thank you. Peter. It seems the patch may have been lost during our earlier > communication, so I¡¯ve reattached it here. > I hope it comes through correctly this time. Thanks for the patch. Using wcsncpy in search_locale_enum() seems fine, assuming it exists on Windows (note

回复: Fix potential overflow risks from wcscpy and sprintf

Thank you. Peter. It seems the patch may have been lost during our earlier communication, so I’ve reattached it here. I hope it comes through correctly this time. Best regards, Haibo 发件人: Peter Eisentraut 发送时间: 2025年6月11日 00:43 收件人: Yan Haibo ; pgsql-hackers@lis

Re: No error checking when reading from file using zstd in pg_dump

Daniel Gustafsson writes: > On 16 Jun 2025, at 16:20, Tom Lane wrote: >> This API is actually quite bizarrely defined, if you ask me. >> Returning the byte count is optional, but if you don't pay >> attention to the byte count you cannot know if you got any >> data. At best, that's bug-encouragi

Re: Per-role disabling of LEAKPROOF requirements for row-level security?

Nathan Bossart writes: > Sorry for going on a bit of a tangent, but why is enum_eq not marked > leakproof when its code looks like this? Perhaps it could be, but I'm not sure how useful that is if we don't mark the remaining enum comparison functions leakproof. There might be a genuine hazard if

Re: Per-role disabling of LEAKPROOF requirements for row-level security?

Sorry for going on a bit of a tangent, but why is enum_eq not marked leakproof when its code looks like this? Datum enum_eq(PG_FUNCTION_ARGS) { Oid a = PG_GETARG_OID(0); Oid b = PG_GETARG_OID(1);

Re: amcheck support for BRIN indexes

Hi! Nice feature! > On 8 Jun 2025, at 17:39, Arseniy Mukhin wrote: > > +#define BRIN_MAX_PAGES_PER_RANGE 131072 I'd personally prefer some words on where does this limit come from. I'm not a BRIN pro, just curious. Or, at least, maybe we can use a form 128 * 1024, if it's just a sane

Returning nbtree posting list TIDs in DESC order during backwards scans

Currently, nbtree always returns individual posting list TIDs to the scan in ASC order -- even during a backwards scan (more on why the deduplication patch deliberately did things that way later). But allowing backwards scans to return TIDs in "somewhat descending order" like this results in needle

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hey Mihail, I've started looking at the patches today, mostly the STIR part. Seems solid, but I've got a question about validation. Why are we still grabbing tids from the main index and sorting them? I think it's to avoid duplicate errors when adding tuples from STIP to the main index, but could

Re: Per-role disabling of LEAKPROOF requirements for row-level security?

Yugo Nagata writes: > Andreas Lind wrote: >> I dug into the code and noticed that restrictinfo->leakproof is only >> being checked in two places (createplan.c and equivclass.c), so it seems >> fairly easy to only selectively enforce it. Then there's the question of >> how to configure it. I can t

Re: Amcheck verification of GiST and GIN

Thanks. I went through the patches, polished the commit messages and did some minor tweaks in patch 0002 (to make the variable names a bit more consistent, and reduce the scope a little bit). I left it as a separate patch to make the changes clearer, but it should be merged into 0002. Please read

Re: Non-reproducible AIO failure

On 16/06/2025 6:11 pm, Andres Freund wrote: Hi, On 2025-06-16 14:11:39 +0300, Konstantin Knizhnik wrote: One more update: with the proposed patch (memory barrier before `ConditionVariableBroadcast` in `pgaio_io_process_completion` I don't see how that barrier could be required for correctness

Re: CHECKPOINT unlogged data

Re: Nathan Bossart > I think you've got it right. With CHECKPOINT_WAIT set, RequestCheckpoint() > will wait for a new checkpoint to start, at which point we know that the > new flags have been seen by the checkpointer. If an immediate checkpoint > is pending, CheckpointWriteDelay() will skip slee

Re: No error checking when reading from file using zstd in pg_dump

> On 16 Jun 2025, at 16:20, Tom Lane wrote: > > Daniel Gustafsson writes: >>> On 16 Jun 2025, at 15:56, Tom Lane wrote: >>> I've not checked to see what the other users of this API do, but >>> if they're all like this then we need to fix that comment. > >> AFAICT all other callers of this API

Re: CHECKPOINT unlogged data

On Mon, Jun 16, 2025 at 04:36:59PM +0200, Christoph Berg wrote: > I spent some time digging through the code, but I'm still not entirely > sure what's happening. There are several parts to it: > > 1) the list of buffers to flush is determined at the beginning of the > checkpoint, so running a 2nd

Re: Non-reproducible AIO failure

Hi, On 2025-06-16 14:11:39 +0300, Konstantin Knizhnik wrote: > One more update: with the proposed patch (memory barrier before > `ConditionVariableBroadcast` in `pgaio_io_process_completion` I don't see how that barrier could be required for correctness - ConditionVariableBroadcast() is a barrier

Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM

On Thu, 5 Jun 2025 16:52:00 +0900 Yugo Nagata wrote: > On Thu, 5 Jun 2025 10:08:35 +0900 > Yugo Nagata wrote: > > > Hi, > > > > Currently, tab completion for COPY only suggests filenames after TO or > > FROM, even though STDIN, STDOUT, and PROGRAM are also valid syntax options. > > > > I'd li

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Fri, Jun 13, 2025 at 10:12 AM John Naylor wrote: > > (Swapping this part back in my brain as well...) I actually don't > think we need that where clause anymore since mwm can be super low > now, and it's a bit mysterious what it was trying to accomplish. Maybe > we can just use the lowest fill

Re: Per-role disabling of LEAKPROOF requirements for row-level security?

Hi, On Sat, 19 Apr 2025 18:14:01 +0200 Andreas Lind wrote: > Hi hackers, > > Row-level security is an awesome feature. I was originally won over by > the simple mental model of implicitly adding WHERE clauses to all > queries, and that it generally comes for free when they can be > satisfied by

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-06-16 17:28:31 +0300, Yura Sokolov wrote: > 04.06.2025 00:04, Andres Freund пишет: > > Hi, > > > > On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote: > >> But still problem of spin lock contention is here. > > > > I still would like to see a reproducer for this. > > For problem in si

Re: Fwd: dsm_registry: Add detach and destroy features

On Mon, Jun 16, 2025 at 09:02:22AM +0900, Sungwoo Chang wrote: > 2025년 6월 14일 (토) 오전 6:50, Nathan Bossart 님이 작성: >> Could your use-case be handled with a DSA? On the other thread [0], we're >> talking about adding a GetNamedDSA() function, which returns a DSA that you >> can use to allocate and fr

Re: CHECKPOINT unlogged data

Re: Laurenz Albe > How about the following for added clarity: > >Running an explicit CHECKPOINT is not required during >normal operation; the system schedules checkpoints automatically > (controlled >by the settings in ). >However, it can be useful to perform an explicit checkpoin

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

04.06.2025 00:04, Andres Freund пишет: > Hi, > > On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote: >> But still problem of spin lock contention is here. > > I still would like to see a reproducer for this. For problem in sinvaladt.c we have no synthetic reproducer. But version with changed maxMs

Re: [PATCH] Remove unused #include's in src/backend/utils/adt/*

Hi Tom, > The removals of bother me a bit; I believe those used > to be necessary on some platforms. Maybe nowadays everybody is > close enough to POSIX that you can safely extrapolate from what > clangd says on your own machine, but it's not zero-risk. Sounds good to me, let's keep . -- Best

Re: No error checking when reading from file using zstd in pg_dump

Daniel Gustafsson writes: >> On 16 Jun 2025, at 15:56, Tom Lane wrote: >> I've not checked to see what the other users of this API do, but >> if they're all like this then we need to fix that comment. > AFAICT all other callers of this API are throwing an error with pg_fatal, and > so does the f

Re: No error checking when reading from file using zstd in pg_dump

> On 16 Jun 2025, at 15:56, Tom Lane wrote: > I've not checked to see what the other users of this API do, but > if they're all like this then we need to fix that comment. AFAICT all other callers of this API are throwing an error with pg_fatal, and so does the function in question for ZStd deco

Re: [PATCH] Remove unused #include's in src/backend/utils/adt/*

Aleksander Alekseev writes: > clangd indicates that certain #include's are redundant. Removing them > will speed up the build process a bit. The removals of bother me a bit; I believe those used to be necessary on some platforms. Maybe nowadays everybody is close enough to POSIX that you can sa

Re: No error checking when reading from file using zstd in pg_dump

I think the real problem here is that what the code is doing is precisely not what is documented in compress_io.h: /* * Read 'size' bytes of data from the file and store them into 'ptr'. * Optionally it will store the number of bytes read in 'rsize'. * * Returns true on suc

Re: pg_upgrade fails with an error "object doesn't exist"

Daniel Gustafsson writes: > On 16 Jun 2025, at 09:29, Vaibhav Dalvi > wrote: >> Why can't we strictly restrict object creation in pg_catalog? > Do you have allow_system_table_mods set to ON by any chance? As Laurenz said, > such creation is already restricted, but it can be circumvented by usi

Re: relrewrite not documented at the top of heap_create_with_catalog()

On Mon, 16 Jun 2025 16:51:46 +0800 Steven Niu wrote: > Hi, Michael, > > The change looks good to me. > > I made more change based on your patch to combine the old comment. I think it's a good idea to move the description of heap_create_with_catalog directly above the function itself, as it see

Re: Add XMLNamespaces to XMLElement

rebase -- Jim From 9c36deb99e600fe9a76fd1942081f3031bbd6216 Mon Sep 17 00:00:00 2001 From: Jim Jones Date: Mon, 16 Jun 2025 14:43:11 +0200 Subject: [PATCH v8] Add XMLNamespaces option to XMLElement This patch adds the scoped option XMLNamespaces to the XMLElement() function, as described in ISO

Re: pg_upgrade fails with an error "object doesn't exist"

> On 16 Jun 2025, at 10:59, Vaibhav Dalvi > wrote: > It's OFF. > postgres=# select version(); > version > > --

Re: Commitfest app release at half June

On Sat, 31 May 2025 at 13:47, Jelte Fennema-Nio wrote: > > I realized two smallish commitfest app improvements were merged but > not deployed yet for quite some time. > 1. There's now a similar summary at the top of the "Personal > Dashboard" page, as is on regular commitfest pages. Thanks to Aksh

Re: Conflict detection for update_deleted in logical replication

On Thu, Jun 12, 2025 at 11:34 AM Zhijie Hou (Fujitsu) wrote: > Few comments on v36 patches: == 1. In advance_conflict_slot_xmin(), we first save the slot to disk, then update its effective xmin, and then do the required xmin computation. Now, if we don't save the slot ever

RE: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

Dear Alexander, > Thank you! All of these totally make sense. The updated patch is attached. Thanks for the update. I found another point. ``` -# Another 2M rows; that's about 260MB (~20 segments) worth of WAL. +# Another 50K rows; that's about 86MB (~5 segments) worth of WAL. $node->safe_psq

Re: Conflict detection for update_deleted in logical replication

On Mon, Jun 16, 2025 at 9:29 AM Zhijie Hou (Fujitsu) wrote: > > 0001: > * Removed the slot acquisition as suggested above. > > 0002: > * Addressed the comments above. > Thanks for the patches. In advance_conflict_slot_xmin(), if new_xmin is same as slot's current xmin, then shall we simply retu

Re: [PATCH] Add an ldflags_sl meson build option

On 16.06.25 06:10, Matt Smith (matts3) wrote: Currently there doesn't seem to be a way to pass shared library-specific flags via a meson build option. This patch allows the existing ldflags_sl to be set via a build option. What uses do you have in mind for this?

[PATCH] Add an ldflags_sl meson build option

Currently there doesn't seem to be a way to pass shared library-specific flags via a meson build option. This patch allows the existing ldflags_sl to be set via a build option. Patch created against the 17.4 release. diff --git a/meson.build b/meson.build index 42a4d25bfd7..68690e5de52 100644 --

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

Dear Kuroda-san, On Mon, Jun 16, 2025 at 12:11 PM Hayato Kuroda (Fujitsu) wrote: > Thanks for pushing the fix patch! BTW, I have few comments for your commits. > Can you check and include them if needed? > > 01. > ``` > $node->append_conf('postgresql.conf', > "shared_preload_libraries = '

Re: Non-reproducible AIO failure

One more update: with the proposed patch (memory barrier before `ConditionVariableBroadcast` in `pgaio_io_process_completion` and replacing bit fields with `uint8`) the problem is not reproduced at my system during 5 seconds.

[PATCH] Remove unused #include's in src/backend/utils/adt/*

Hi, clangd indicates that certain #include's are redundant. Removing them will speed up the build process a bit. -- Best regards, Aleksander Alekseev v1-0001-Remove-unused-include-s-in-src-backend-utils-adt.patch Description: Binary data

Re: [PATCH] Split varlena.c into varlena.c and bytea.c

Hi Peter, > >> The proposed patch extracts the code dealing with bytea from varlena.c > >> into a separate file, as proposed previously [1]. It merely changes > >> the location of the existing functions. There are no other changes. > > > > Rebased. > > I think this is reasonable. varlena.c is pre

  1   2   >