Re: Extended Statistics set/restore/clear functions.

On Sat, Nov 22, 2025 at 03:26:19AM -0500, Corey Huinker wrote: > I added a comment debating the feasibility of testing for subsets of > attribute sets in pg_dependencies. Basically, I think we can't have the > test at all, but I haven't removed it just yet pending consensus. + * Verify that al

Re: Enhancing Memory Context Statistics Reporting

Hi Daniel, Thank you for your comments. Please find attached v41 with all the comments addressed. > > +#include "access/twophase.h" > +#include "catalog/pg_authid_d.h" > ... > +#include "utils/acl.h" > Are these actually required to be included? > > Removed these. > - MemoryContextId *en

Re: Add 64-bit XIDs into PostgreSQL 15

hi Maxim I saw (make mxidoff 64 bits) path need more guys review and pg_resetwal need support mxidoff 64,do we need to invite more to review ? Thanks On Tue, Nov 25, 2025 at 2:12 PM Maxim Orlov wrote: > > Here is a rebase @ 4d3f623ea88 > > The patch set has grown increasingly old. It appe

Re: Resetting recovery target parameters in pg_createsubscriber

It seems my previous message isn't visible in the thread. I can see Robert's reply, but not the original message he was responding to. I'm resending the message and all attachments to ensure it's saved in the thread. On Thu, 13 Nov 2025 at 19:45, Alena Vinter wrote: > Hi everyone! > > Robert, he

Re: pg_waldump: support decoding of WAL inside tarfile

On Fri, Nov 21, 2025 at 5:14 PM Amul Sul wrote: > > On Wed, Nov 19, 2025 at 1:50 PM Jakub Wartak > wrote: > > > > On Mon, Nov 17, 2025 at 5:51 AM Amul Sul wrote: > > > > > > On Thu, Nov 6, 2025 at 2:33 PM Amul Sul wrote: > > > > > > > > On Mon, Oct 20, 2025 at 8:05 PM Robert Haas > > > > wrot

Re: Row pattern recognition

> On Nov 24, 2025, at 08:59, Chao Li wrote: > > I will proceed 0007 tomorrow. I just finished reviewing 0007 and 0008. This patch set really demonstrates the full lifecycle of adding a SQL feature, from changing the syntax in gram.y all the way down to the executor, including tests and docs

Re: more C99 cleanup

Peter Eisentraut writes: > On 21.11.25 17:10, Tom Lane wrote: >> Ah, there are several. It's not totally obvious perhaps where the >> cause is. I'll attach the diffs just for the archives' sake. > For clarification, does what you are showing mean that the regression > tests have enough coverag

Re: headerscheck ccache support

On 22.11.25 09:54, Thomas Munro wrote: On Fri, Nov 21, 2025 at 11:48 PM Peter Eisentraut wrote: Currently, headerscheck and cpluspluscheck are very slow, and they defeat use of ccache. I have fixed that, and now they are much faster. :-) The problem was (I think) that the test files are creat

Re: Fixes bug in strlower_libc_sb()

On Tue, Nov 25, 2025 at 11:03 AM Chao Li wrote: > Hi Hackers, > > While reviewing Jeff's patch [1], I found this bug in strlower_libc_sb(): > > ``` > static size_t > strlower_libc_sb(char *dest, size_t destsize, const char *src, ssize_t > srclen, > pg_locale_t locale) > { > if (srclen < 0) > srcl

Re: more C99 cleanup

On 21.11.25 17:10, Tom Lane wrote: I wrote: I have a distinct recollection that this comment exists because we found that some platforms had a hypot() that got that edge case wrong. I don't object to proceeding on the assumption that they all conform to spec by now, but please make sure there's

Re: Remove useless casting to the same type

Hi, On Mon, Nov 24, 2025 at 03:18:00PM -0800, Jacob Champion wrote: > On Mon, Nov 24, 2025 at 2:26 AM Bertrand Drouvot > wrote: > > Attached is a patch to $SUBJECT. > > > --- a/src/backend/access/gin/gindatapage.c > > +++ b/src/backend/access/gin/gindatapage.c > > @@ -607,11 +607,11 @@ dataBegin

Re: more C99 cleanup

On 21.11.25 15:03, Thomas Munro wrote: On Sat, Nov 22, 2025 at 2:50 AM Peter Eisentraut wrote: + * %z doesn't actually act differently from %Z on Windows. Probably obsolete too, at least according to: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-

Re: Remove useless casting to the same type

Hi, On Mon, Nov 24, 2025 at 12:43:28PM -0600, Nathan Bossart wrote: > On Mon, Nov 24, 2025 at 10:26:32AM +, Bertrand Drouvot wrote: > > This is the same kind of idea as 7f798aca1d5 and ef8fe693606, as their > > presence > > could cause risks of hiding actual type mismatches in the future or s

Re: [Proposal] Adding TRIM_SPACE option to COPY

Fujii Masao writes: > On Tue, Nov 25, 2025 at 1:18 AM 河田達也 wrote: >> I'd like to propose adding a new option, TRIM_SPACE, to the COPY command. > I like this idea in general. I'm kind of down on it, because it's inevitably going to add processing overhead to every COPY operation whether the feat

Re: [Proposal] Adding TRIM_SPACE option to COPY

On Tue, Nov 25, 2025 at 1:18 AM 河田達也 wrote: > > Hi, > > I'd like to propose adding a new option, TRIM_SPACE, to the COPY command. > > Other data warehouse systems such as Snowflake provide similar functionality > (TRIM_SPACE) to improve robustness when loading CSV data. PostgreSQL does not > curr

Re: [Proposal] Adding TRIM_SPACE option to COPY

HI, This change seems very useful, I participated in a related project before. After reviewing the patch, I have a suggestion, would it be better to restrict the change to only "copy from"? [email protected] From: 河田達也 Date: 2025-11-25 00:17 To: pgsql-hackers Subject: [Proposal] Adding

Re: Patch: dumping tables data in multiple chunks in pg_dump

On Tue, Nov 25, 2025 at 2:32 AM Hannu Krosing wrote: > > The expectation was that as chunking is useful mainly in case of > really huge tables the analyze should have been run "recently enough". > > Maybe we should use pg_relation_size() in case we have already > determined that the table is large

Re: proposal: schema variables

Hi I am sending a link to our wiki with general description of implementations of session variables in mayor RDBMS https://wiki.postgresql.org/wiki/Implementation_of_declarative_catalog_session_variables Regards Pavel

Re: backend/nodes cleanup: Move loop variables definitions into for statement

On Tue, Nov 25, 2025 at 7:38 AM Chao Li wrote: > > On Mon, Nov 24, 2025 at 11:00 PM Peter Eisentraut > wrote: > >> On 19.11.25 11:32, Chao Li wrote: >> > On Wed, Nov 19, 2025 at 5:36 PM Peter Eisentraut > > > wrote: >> > >> > >> > >> > In a couple of cases, you a

Re: Proposal: Conflict log history table for Logical Replication

Hi Dilip. Here are a couple of review comments for v6-0001. == GENERAL. 1. Firstly, here is one of my "what if" ideas... The current patch is described as making a "structured, queryable record of all logical replication conflicts". What if we go bigger than that? What if this were made a

Fixes bug in strlower_libc_sb()

Hi Hackers, While reviewing Jeff's patch [1], I found this bug in strlower_libc_sb(): ``` static size_t strlower_libc_sb(char *dest, size_t destsize, const char *src, ssize_t srclen, pg_locale_t locale) { if (srclen < 0) srclen = strlen(src); if (srclen + 1 <= destsize) { locale_t loc = locale->

Re: Add mode column to pg_stat_progress_vacuum

On Tue, Nov 25, 2025 at 8:13 AM Masahiko Sawada wrote: > > What about “started_by” ? it’s unambiguous and consistent with other columns > > like “query_start” in pg_stat_activity. > > "started_by" sounds reasonable to me. Thanks all. I've updated the patches to use "started_by" and replaced remai

Re: [Proposal] Adding callback support for custom statistics kinds

On Mon, Nov 24, 2025 at 06:18:26PM -0600, Sami Imseih wrote: > After second thought, I am not too thrilled with extending reset_all_cb > to take responsibility for file cleanup, etc. I think it should just remain > used to reset stats only. > > I think the best way forward will be to introduce a c

Re: Partial hash index is not used for implied qual.

I wrote: > Wouldn't it be better to handle it more like the is_target_rel logic > a few lines further up? Actually, after thinking a bit longer, it'd be better to do something like the attached so that we don't keep redundant quals unless they'd *all* be excluded. There's definitely something fis

Re: generic plans and "initial" pruning

On Sun, Nov 23, 2025 at 9:17 PM Tender Wang wrote: > Amit Langote 于2025年11月20日周四 15:30写道： >> >> On Mon, Nov 17, 2025 at 9:50 PM Amit Langote wrote: >> > On Wed, Nov 12, 2025 at 11:17 PM Amit Langote >> > wrote: >> > > * Enable pruning-aware locking in cached / generic plan reuse (0004): >> > >

Re: Remaining dependency on setlocale()

Hi Jeff, I have reviewed 0001-0004 and got a few comments: > On Nov 25, 2025, at 07:57, Jeff Davis wrote: > > > 0001-0004: Pure refactoring patches. I intend to commit a couple of > these soon. > 1 - 0001 ``` +/* + * Fold a character to upper case, following C/POSIX locale rules. + */ +stati

Re: Partial hash index is not used for implied qual.

David Rowley writes: > so, that leads me to believe the location you're adjusting is probably > the best place to fix this issue. Wouldn't it be better to handle it more like the is_target_rel logic a few lines further up? I also object to putting the test between the contain_mutable_functions a

Re: [PATCH] Write Notifications Through WAL

Hi all, following up with a new rebased patch. > > On Fri, Oct 17, 2025 at 6:33 AM Arseniy Mukhin > > wrote: > > > Also the comment > > > > > > /*-- > > > * Get snapshot we'll use to decide which xacts are still in progress. > > > * This is trickier than it might seem, becau

Re: Partial hash index is not used for implied qual.

On Mon, 24 Nov 2025 at 20:33, Sergei Glukhov wrote: > Partial hash index is not used if qual is an implied qual > since this qual is not added to indrestrictinfo and we cannot > get the keys needed to make hash index scan possible. > Suggested fix is to add implied qual for the indexes > which req

Re: [Proposal] Adding callback support for custom statistics kinds

> After re-reading your earlier suggestions, this sounds like a third > callback that is used for file cleanup, and this callback could be > the existing reset_all_cb. Also, instead of reset_all_cb being called > during pgstat_reset_after_failure, it can be called during the success > case, i.e, a

Re: Buffer locking is special (hints, checksums, AIO writes)

Hi, On 2025-11-24 16:04:41 -0500, Melanie Plageman wrote: > On Mon, Nov 24, 2025 at 3:58 PM Andres Freund wrote: > > On 2025-11-19 21:47:49 -0500, Andres Freund wrote: > > > 0001: A straight-up bugfix in lwlock.c - albeit for a bug that seems > > > currently > > > effectively harmless. > >

Re: Buffer locking is special (hints, checksums, AIO writes)

On Fri, Nov 21, 2025 at 9:51 AM Andres Freund wrote: > It's worth pointing out that the new way of setting hint bits is inherently > more expensive than what we did before - upgrading a lock to a different lock > level isn't free, compared to doing, well, nothing. > > For paths that set the hint b

Re: Remaining dependency on setlocale()

On Thu, 2025-11-20 at 16:58 -0800, Jeff Davis wrote: > On Wed, 2025-11-12 at 19:59 +0100, Peter Eisentraut wrote: > > Many of these issues are pre-existing, but I just figured it has > > reached > > a point where we need to do something about it. > > I tried to simplify things in this patch serie

Re: backend/nodes cleanup: Move loop variables definitions into for statement

On Mon, Nov 24, 2025 at 11:00 PM Peter Eisentraut wrote: > On 19.11.25 11:32, Chao Li wrote: > > On Wed, Nov 19, 2025 at 5:36 PM Peter Eisentraut > > wrote: > > > > > > > > In a couple of cases, you are changing the type of the loop variable > > from Size to

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

On Thu, Nov 13, 2025 at 11:55 PM Yugo Nagata wrote: > > Hi Sawada-san, > > I still cannot confirm that my previous email has been archived [1], > so let me resend it. > I apologize again for the repeated emails. > > [1] https://www.postgresql.org/list/pgsql-hackers/since/20251113/ > > On Tue,

Re: Serverside SNI support in libpq

Hi Daniel, None of my comment on v9 are addressed in v10: > > 1 - commit message > ``` > Experimental support for serverside SNI support in libpq, a new config > file $datadir/pg_hosts.conf is used for configuring which certicate and > ``` > > Typo: certicate -> certificate > > 2 - be-secure-c

Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ​barriers

Hi, On 2025-11-24 11:28:28 -0500, Greg Burd wrote: > @@ -2509,25 +2513,64 @@ int main(void) > } > ''' > > - if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd > without -march=armv8-a+crc', > - args: test_c_args) > -# Use ARM CRC Extension unconditionally > -

Re: Remove useless casting to the same type

On Mon, Nov 24, 2025 at 2:26 AM Bertrand Drouvot wrote: > Attached is a patch to $SUBJECT. > --- a/src/backend/access/gin/gindatapage.c > +++ b/src/backend/access/gin/gindatapage.c > @@ -607,11 +607,11 @@ dataBeginPlaceToPageLeaf(GinBtree btree, Buffer buf, > GinBtreeStack *stack, > > if (appe

Re: Add mode column to pg_stat_progress_vacuum

On Wed, Nov 19, 2025 at 11:28 PM Sami Imseih wrote: >> >> I'd +1 for triggered_by over just trigger, but I actually think >> triggered_by should be avoided as well for the same reason (term >> overload). We already use the verb "launch" as the word to describe >> this action in the existing autova

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Hello, Álvaro! On Mon, Nov 24, 2025 at 6:49 PM Álvaro Herrera wrote: > This patch would bring the committed test file up to date with what you > last submitted. However, I didn't understand what is the problem with > the original formulation, and I haven't seen the test fail ... can you > explai

Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

Hi, On 2025-11-20 12:19:58 -0500, Melanie Plageman wrote: > From 363f0e4ac9ac7699a6d9c2a267a2ad60825407c8 Mon Sep 17 00:00:00 2001 > From: Melanie Plageman > Date: Mon, 17 Nov 2025 15:11:27 -0500 > Subject: [PATCH v22 1/9] Split heap_page_prune_and_freeze() into helpers > > Refactor the setup and

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

On Mon, Nov 24, 2025 at 06:49:47PM +0100, Alvaro Herrera wrote: > This patch would bring the committed test file up to date with what you > last submitted. However, I didn't understand what is the problem with > the original formulation, and I haven't seen the test fail ... can you > explain? Rea

Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations

On Mon, Nov 24, 2025 at 4:18 PM Hannu Krosing wrote: > When VACUUM decides which rows are safe to freeze or permanently > remove it currently ignores backends which have PROC_IN_VACUUM or > PROC_IN_LOGICAL_DECODING bits set. > > This patch adds PROC_IN_SAFE_IC to this set, so backends running > CR

Re: warning on the current head

On Wed, Nov 19, 2025 at 08:43:52PM +0100, Viktor Holmberg wrote: > For anyone else experiencing this - I had the same problem. make > distclean and re-configure solved it as Álvaro suggested. Another one, which is more drastic for builds inside the tree, is the following: git clean -dxf I have be

Re: Speed up COPY FROM text/CSV parsing using SIMD

On Thu, Nov 20, 2025 at 03:55:43PM +0300, Nazir Bilal Yavuz wrote: > On Thu, 20 Nov 2025 at 00:01, Nathan Bossart wrote: >> +/* Load a chunk of data into a vector register */ >> +vector8_load(&chunk, (const uint8 *) >> ©_input_buf[input_buf_ptr]); >> >> In other places, pr

Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section

On Mon, Nov 24, 2025, at 17:06, Tom Lane wrote: > I don't think Joel did anybody any favors by separating this patch > fragment from its larger context [1]. I'm a bit surprised by this. My intention in splitting it out was based on earlier advice in [1] that I think made a lot of sense: >> [...my

Re: [PATCH] Add error hints for invalid COPY options

On Mon, Nov 24, 2025 at 11:56:34AM -0800, Masahiko Sawada wrote: > On Sat, Nov 22, 2025 at 8:33 PM Sugamoto Shinya wrote: >> This follows the pattern already used elsewhere in PostgreSQL for providing >> helpful error hints to users. > > Given we have 15 COPY options now, it sounds like a reasona

Re: Skipping schema changes in publication

Hi Shlok. I checked the latest v28-0004 "EXCEPT (col-list)" patch. I have no code review comments, but I do have one syntax question. == The result of the current patch proposed syntax is like: CREATE PUBLICATION pubname FOR TABLE tabname EXCEPT (col1, col2, col3) ALTER PUBLICATION pubname

Re: index prefetching

On Mon, Nov 24, 2025 at 3:48 PM Andres Freund wrote: > Huh. I wouldn't have expected -march=native to make a huge difference... Me neither. On the other hand I find that this area is quite sensitive to icache misses and branch misprediction penalties. This is partly due to my holding the patch to

Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE

On Fri, Nov 21, 2025 at 8:26 AM 河田達也 wrote: > > Hi Sawada-san, > > Thank you for your additional feedback on v4! > > >We can initialize dead_items_max_bytes when declared. > Thank you. I fixed it as you mentioned. > > >Does it need to check if vacrel->dead_items is non-NULL? > Thank you. I fixed i

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

On Mon, Nov 24, 2025 at 04:02:18PM -0500, Robert Haas wrote: > I haven't done a full review of this and I'm not sure whether you want > me to spend more time on it... I'd appreciate an eyeball check if you have the time. > I'm guessing that the reason why that doesn't easily work is > because you

Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations

When VACUUM decides which rows are safe to freeze or permanently remove it currently ignores backends which have PROC_IN_VACUUM or PROC_IN_LOGICAL_DECODING bits set. This patch adds PROC_IN_SAFE_IC to this set, so backends running CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY and where the ind

Re: Add notification on BEGIN ATOMIC SQL functions using temp relations

Jim Jones writes: > While playing with v9 I realised that this issue also affects > non-temporary tables when they use temporary types (in pg_temp):: Right. Really the dependency-on-temp-type scenario affects a ton of object types: aggregates, casts, domains, operators, you name it. > The colum

Re: Buffer locking is special (hints, checksums, AIO writes)

On Mon, Nov 24, 2025 at 3:58 PM Andres Freund wrote: > > Hi, > > On 2025-11-19 21:47:49 -0500, Andres Freund wrote: > > 0001: A straight-up bugfix in lwlock.c - albeit for a bug that seems > > currently > > effectively harmless. > > Does anybody have opinions about whether to backpatch this

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

On Mon, Nov 24, 2025 at 2:03 PM Nathan Bossart wrote: > I think 0002 was more complicated than necessary. Here's a second try. I haven't done a full review of this and I'm not sure whether you want me to spend more time on it, but something I notice about this version is that the PG_CATCH() bloc

Re: Patch: dumping tables data in multiple chunks in pg_dump

The expectation was that as chunking is useful mainly in case of really huge tables the analyze should have been run "recently enough". Maybe we should use pg_relation_size() in case we have already determined that the table is large enough to warrant chunking? Maybe at least 1/2 of the requested

Re: Buffer locking is special (hints, checksums, AIO writes)

Hi, On 2025-11-19 21:47:49 -0500, Andres Freund wrote: > 0001: A straight-up bugfix in lwlock.c - albeit for a bug that seems currently > effectively harmless. Does anybody have opinions about whether to backpatch this fix? Given that it has no real consequences I'm mildly inclined not to,

Re: should we have a fast-path planning for OLTP starjoins?

On Sun, Nov 23, 2025 at 9:39 AM Tomas Vondra wrote: > > 1. I do not think I believe the premise that the dimension tables > > typically won't have restriction clauses. ISTM that a typical > > query might be like > > > > select sum(o.total_price) from > > orders o > > join custom

Re: index prefetching

Hi, On 2025-11-23 19:03:44 -0500, Peter Geoghegan wrote: > On Fri, Nov 21, 2025 at 6:31 PM Andres Freund wrote: > > On 2025-11-21 18:14:56 -0500, Peter Geoghegan wrote: > > > On Fri, Nov 21, 2025 at 5:38 PM Andres Freund wrote: > > > > Another benfit is that it helps even more when there multipl

Re: [PATCH] Reorganize pqcomm.h a bit

On Mon, Nov 24, 2025 at 1:33 AM Heikki Linnakangas wrote: > On 22/11/2025 03:53, Jelte Fennema-Nio wrote: > > Looks fine to me > > +1 Committed; thank you both! --Jacob

Re: Post-release followup: pg_add_size_overflow()

On Wed, Nov 19, 2025 at 9:46 AM Jacob Champion wrote: > Done with a standard comment in v2, attached. Or were you also > suggesting that I should just get rid of the sample, and rely on the > comment above it? Pushed v2; let me know if some other documentation style would be more helpful. Thank

Re: anonymous unions (C11)

On Fri, Oct 17, 2025 at 7:23 AM Nathan Bossart wrote: > LGTM (Pushed, thanks!) --Jacob

Re: get rid of Pointer type, mostly

On 24.11.2025 20:52, Robert Haas wrote: > On Mon, Nov 24, 2025 at 2:38 PM Tom Lane wrote: >> Well, either Peter just ran out of energy or there is actually some >> notational value in Pointer. If it's the latter, I'd like to know. > > I agree that would be nice to know. > > Peter's original ema

Re: get rid of Pointer type, mostly

Tom Lane writes: > Robert Haas writes: >> On Mon, Nov 24, 2025 at 1:46 PM David Geier wrote: >>> The GIN code makes use of pointer but src/backend/access/gin only has 29 >>> occurrences. If you like I can help out fixing up the GIN code and share >>> a page here. Let me know. > >> I'd go for it

Re: should we have a fast-path planning for OLTP starjoins?

On Sun, Nov 23, 2025 at 03:53:17PM +0100, Tomas Vondra wrote: > >> The only reason to join a dimension table that lacks a restriction > >> clause is if you need some of its fields in the output, which you > >> might but I'm not sure that's such a common case. (Have you got > >> evidence to the con

Re: another autovacuum scheduling thread

On Sun, Nov 23, 2025 at 4:55 AM David Rowley wrote: > One thing that seems to be getting forgotten again is the "/* Stop > applying cost limits from this point on */" added in 1e55e7d17 is only > going to be applied when the table *currently* being vaccumed is over > the failsafe limit. Without Na

Re: [PATCH] Add error hints for invalid COPY options

Hi, On Sat, Nov 22, 2025 at 8:33 PM Sugamoto Shinya wrote: > > Hi, > > This patch improves the user experience when working with COPY commands by > adding helpful error hints for invalid options. > > Currently, when users make typos in COPY option names or values, they receive > a generic error m

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 2:38 PM Tom Lane wrote: > Well, either Peter just ran out of energy or there is actually some > notational value in Pointer. If it's the latter, I'd like to know. I agree that would be nice to know. Peter's original email seemed to indicate that he was deterred by this s

Re: get rid of Pointer type, mostly

Robert Haas writes: > On Mon, Nov 24, 2025 at 1:26 PM Tom Lane wrote: >> I don't understand leaving it in place for GIN. > I haven't tried removing it for GIN so I don't know how awkward that > would be or for what reasons, but... Well, either Peter just ran out of energy or there is actually s

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 1:26 PM Tom Lane wrote: > I don't understand leaving it in place for GIN. I haven't tried removing it for GIN so I don't know how awkward that would be or for what reasons, but... > It's > not like GIN indexes are some hoary backwater that nobody pays > attention to. ...

Re: Assertion failure in SnapBuildInitialSnapshot()

On Mon, Nov 24, 2025 at 10:48 AM Masahiko Sawada wrote: > > On Mon, Nov 24, 2025 at 1:46 AM Amit Kapila wrote: > > > > On Fri, Nov 21, 2025 at 9:17 AM Zhijie Hou (Fujitsu) > > wrote: > > > > > > On Thursday, November 13, 2025 12:56 PM Zhijie Hou (Fujitsu) > > > wrote: > > > > > > > > > > I hav

Re: get rid of Pointer type, mostly

Robert Haas writes: > On Mon, Nov 24, 2025 at 1:46 PM David Geier wrote: >> The GIN code makes use of pointer but src/backend/access/gin only has 29 >> occurrences. If you like I can help out fixing up the GIN code and share >> a page here. Let me know. > I'd go for it! I mean, who knows whether

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 1:46 PM David Geier wrote: > The GIN code makes use of pointer but src/backend/access/gin only has 29 > occurrences. If you like I can help out fixing up the GIN code and share > a page here. Let me know. I'd go for it! I mean, who knows whether your patch will be accepted

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

On Mon, Nov 24, 2025 at 12:36:25PM -0600, Nathan Bossart wrote: > On Sat, Nov 22, 2025 at 01:41:21PM -0600, Nathan Bossart wrote: >> I'll give what you suggested a try. It seems reasonable enough. > > Here is a mostly-untested first try. I think 0002 was more complicated than necessary. Here's

Re: Expanding HOT updates for expression and partial indexes

On Sat, 22 Nov 2025, 22:30 Greg Burd, wrote: > Thanks for pointing out the oversight for index-oriented scans (IOS), > you're right that the code in v22 doesn't handle that correctly. I'll > fix that. I still think that indexes that don't support IOS can and > should use the type-specific equali

Re: [oauth] SASL mechanisms

On Mon, Nov 24, 2025 at 09:33:01AM -0800, Jacob Champion wrote: > On Fri, Nov 21, 2025 at 9:24 PM Nico Williams wrote: > > I've not looked in detail yet, but I got the impression that the user > > has to fetch the token on their own and provide it to the PG client -- > > if so that is monumentally

Re: Assertion failure in SnapBuildInitialSnapshot()

On Mon, Nov 24, 2025 at 1:46 AM Amit Kapila wrote: > > On Fri, Nov 21, 2025 at 9:17 AM Zhijie Hou (Fujitsu) > wrote: > > > > On Thursday, November 13, 2025 12:56 PM Zhijie Hou (Fujitsu) > > wrote: > > > > > > > I have been thinking if there a way to avoid holding > > ReplicationSlotControlLock

Re: get rid of Pointer type, mostly

I'm in big favor of this change. Such types just cover up what's really going on and make reading the code more difficult than needed, especially for people new to the code base. On 24.11.2025 19:26, Tom Lane wrote: > Robert Haas writes: > I can follow the argument that using the native type "vo

Re: Remove useless casting to the same type

On Mon, Nov 24, 2025 at 10:26:32AM +, Bertrand Drouvot wrote: > This is the same kind of idea as 7f798aca1d5 and ef8fe693606, as their > presence > could cause risks of hiding actual type mismatches in the future or silently > discarding qualifiers. I think that it also improves readability.

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

On Sat, Nov 22, 2025 at 01:41:21PM -0600, Nathan Bossart wrote: > I'll give what you suggested a try. It seems reasonable enough. Here is a mostly-untested first try. -- nathan >From e639d70a10f6288034ebe433a22b9dbc53562b01 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Mon, 24 Nov 2025 1

Re: get rid of Pointer type, mostly

Robert Haas writes: > But if it were up to me, I'd rip out Pointer completely, because > reading code that uses the native C type names is easier for me than > reading code that substitutes other notation. I can follow the argument that using the native type "void *" is better, since every C prog

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

On 2025-Nov-22, Mihail Nikalayeu wrote: > 2) some updates for 0001 test stability (related to [0]). This patch would bring the committed test file up to date with what you last submitted. However, I didn't understand what is the problem with the original formulation, and I haven't seen the test

Re: Missing wait events (gap analysis)

Hi, On 2025-11-21 18:43:31 -0600, Nikolay Samokhvalov wrote: > Many tools that implement wait event analysis, when visualizing samples > with "wait_event is null" use green color and "CPU" (perhaps, it started > with RDS Performance Insights and PASH Viewer and, I suppose, originally > came from t

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 12:30 PM Jelte Fennema-Nio wrote: > In this case, what we would accomplish is that no new developer to the > project has to understand what some unclear typedef means, *unless* they > touch GIN related code. Just from its name it's definitely not clear to me > that Point

Re: [oauth] SASL mechanisms

On Fri, Nov 21, 2025 at 9:24 PM Nico Williams wrote: > I've not looked in detail yet, but I got the impression that the user > has to fetch the token on their own and provide it to the PG client -- > if so that is monumentally unfriendly by comparison to, e.g., Kerberos. You provide a client ID a

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 11:33 AM Tom Lane wrote: > We have lots of places where we use trivial typedefs to annotate > what something is. For instance "text *" is not really different > from "struct varlena *", but I don't think anyone would be in favor > of removing the "text" typedef. In this c

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025, 09:34 Tom Lane wrote: > Especially so if the removal is incomplete. What have > you really accomplished then? > In this case, what we would accomplish is that no new developer to the project has to understand what some unclear typedef means, *unless* they touch GIN related

Re: Cygwin support

On 2025-11-23 Su 6:44 PM, Thomas Munro wrote: Since this thread discussed possibly bringing back Cygwin buildfarm coverage, you might be interested in this proposed change: https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BBpW%3DKhGHTWGMe0cSETMYZsSygv5jFWD1Y6wcbAn2ecQ%40mail.gmail.com#dad6

Re: Missing wait events (gap analysis)

On 2025-Nov-24, Matthias van de Meent wrote: > On Sat, 22 Nov 2025 at 01:43, Nikolay Samokhvalov wrote: > > Before moving forward with proposals of specific patches, I wanted > > to hear opinions -- does it make sense to work in this direction? > > I don't think it's a bad idea to add wait even

Re: Extended test coverage and docs for SSL passphrase commands

On 2025-Nov-23, Daniel Gustafsson wrote: > > On 22 Nov 2025, at 14:00, Álvaro Herrera wrote: > > I think the parallel to debug_assertions is not perfect, because you > > can turn off debug_assertions in a server built with them included, > > but you cannot turn off EXEC_BACKEND. > > debug_asser

Re: Missing wait events (gap analysis)

On Sat, 22 Nov 2025 at 01:43, Nikolay Samokhvalov wrote: > > Hi hi > > Many tools that implement wait event analysis, when visualizing samples with > "wait_event is null" use green color and "CPU" (perhaps, it started with RDS > Performance Insights and PASH Viewer and, I suppose, originally cam

Re: Issue with logical replication slot during switchover

Hi Masahiko, I agree with your analysis. But why not to take into account the parameter synchronized_standby_slots (garantee the slot on the target has received wal before playing decoded changes). I take your setup. node1 => node2 => node3 node1 is a primary node2 are standby slot1: is a failove

Re: Missing wait events (gap analysis)

On Sun, 23 Nov 2025, 11:28 Darafei "Komяpa" Praliaskouski, wrote: > > Other spots that may be invisible but helpful to keep track of are > serialization/deserialization that happens on IN/OUT functions (so many > surprises when EXPLAIN ANALYZE doesn't account for time to actually serialize > th

Re: get rid of Pointer type, mostly

Robert Haas writes: > On Mon, Nov 24, 2025 at 11:09 AM Tom Lane wrote: >>> The second is getting rid of uses of Pointer for variables where you >>> might as well use void * directly. These are actually not that many. >> ... but not of that. In particular, I think it's just fine if >> DatumGetP

Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ​barriers

On Mon, Nov 24, 2025, at 10:04 AM, Greg Burd wrote: > Hello, > > v3 attached is a more concise single patch that adds support for MSVC > on Win11 ARM64. The issues fixed are mostly related to config, build, > docs, an implementation of spin_delay() and a change to S_UNLOCK() > macro. I've squ

Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 11:09 AM Tom Lane wrote: > > The second is getting rid of uses of Pointer for variables where you > > might as well use void * directly. These are actually not that many. > > ... but not of that. In particular, I think it's just fine if > DatumGetPointer and PointerGetDat

[Proposal] Adding TRIM_SPACE option to COPY

Hi, I'd like to propose adding a new option, TRIM_SPACE, to the COPY command. Other data warehouse systems such as Snowflake provide similar functionality (TRIM_SPACE) to improve robustness when loading CSV data. PostgreSQL does not currently have such an option, although it would be consistent w

Re: pg_plan_advice

On Sat, Nov 22, 2025 at 7:43 PM Dian Fay wrote: > Thanks for working on this, Robert! Thanks for looking at it! I was hoping for a bit more in the way of responses by now, honestly. > Since the policies don't contain any execution boundaries, all the quals > should be going into a single bucket

Re: get rid of Pointer type, mostly

Peter Eisentraut writes: > In a previous thread[0], the question was asked, 'Why do we bother with > a "Pointer" type?'. So I looked into get rid of it. > There are two stages to this. One is changing all code that wants to do > pointer arithmetic to use char * instead of relying on Pointer be

Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section

Heikki Linnakangas writes: > On 23/11/2025 16:45, Joel Jacobson wrote: >> This patch addresses this comment in async.c's SignalBackends: >> * XXX in principle these pallocs could fail, which would be bad. >> * Maybe preallocate the arrays? They're not that large, though. > Ugh. I wonder if we sh

  1   2   >