Re: Statistics Import and Export

On Tue, Feb 25, 2025 at 5:01 AM Jeff Davis wrote: > > On Mon, 2025-02-24 at 15:53 -0500, Andres Freund wrote: > > I don't think that's necessarily true, hot pruning might help some, > > as afaict > > the restore happens in multiple transactions. > > Yeah, I just dumped and reloaded the regression

Re: Change GUC hashtable to use simplehash?

On Sat, Feb 15, 2025 at 12:28 PM John Naylor wrote: > > On Fri, Feb 14, 2025 at 6:40 PM Anton A. Melnikov > wrote: > > Yes, of course. I tested this patch on the current master at 9e17ac997 > > in the same way and found no valgrind errors. > > Thanks, I'll push next week after the next minor rele

Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing

On Mon, Feb 24, 2025 at 01:08:03PM +, Bertrand Drouvot wrote: > I agree that we've to put everything in the picture (system with or without > cheap timing functions, lock contention and WAL flush disk time) and that we > can certainly find configuration/workload that would get benefits from a >

Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

On Tue, Feb 25, 2025 at 3:26 PM Ajin Cherian wrote: > > On Fri, Feb 21, 2025 at 2:24 PM Amit Kapila wrote: > > > > On Fri, Feb 21, 2025 at 7:57 AM Ajin Cherian wrote: > > > In these tests, I also see an increased performance with the patch > > > even when all transactions are published. I will i

Re: pg_copy_logical_replication_slot doesn't copy the failover property

On Mon, Feb 24, 2025 at 4:29 PM Zhijie Hou (Fujitsu) wrote: > > Here is the new V3 patch set which updated the comments to make the > issue clearer. > I pushed your first patch after minor modifications. > After thinking more on the two_phase option, I didn't find an issue that > prevent > us f

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Hi po 24. 2. 2025 v 21:05 odesílatel Gilles Darold napsal: > Review: > > This patch claims to add SQL/PSM named arguments syntax to cursors and > this what it does exactly. > > It compiles without error with master current code and all tests > passed successfully. > > I think it could be ready

Re: Statistics Import and Export

Hi Jeff and Corey, I think I have found a bug (arguably) with the dump/restore test I am developing at [1]. #create table t1 (a int primary key, b int); CREATE TABLE #insert into t1 values (1, 2); INSERT 0 1 $ createdb rdb $ pg_dump -d postgres | psql -d rdb $ pg_dump -d postgres > /tmp/pgdb.ou

Re: Small memory fixes for pg_createsubcriber

On Thu, Feb 13, 2025 at 01:50:29PM +0900, Michael Paquier wrote: > On Wed, Feb 12, 2025 at 07:08:31PM -0500, Tom Lane wrote: >> I spent a little time earlier today seeing what I could do with the >> use-dmalloc patch I posted earlier. It turns out you can get through >> initdb after s/free/PQfreem

Re: Fix untranslatable split message

On Tue, Feb 25, 2025 at 02:09:53PM +0900, Kyotaro Horiguchi wrote: > The recent commit 1aab6805919 introduced a help description that was > split into two printf() commands, making it untranslatable. > > The attached patch merges them into a single message. Good catch, you are right. Will fix. -

Re: Restrict copying of invalidated replication slots

On Tue, 25 Feb 2025 at 01:03, Masahiko Sawada wrote: > > On Mon, Feb 24, 2025 at 3:06 AM Shlok Kyal wrote: > > > > On Sat, 22 Feb 2025 at 04:49, Masahiko Sawada wrote: > > > > > > On Fri, Feb 21, 2025 at 4:30 AM Shlok Kyal > > > wrote: > > > > > > > > On Fri, 21 Feb 2025 at 01:14, Masahiko Saw

Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators

On Mon, Feb 24, 2025 at 6:54 PM Jeff Davis wrote: > > On Mon, 2025-02-24 at 12:46 -0800, James Hunter wrote: > > Attached please find the patch set I mentioned, above, in [1]. It > > consists of 4 patches that serve as the building blocks for and a > > prototype of the "query_work_mem" GUC I propo

Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing

On Tue, Feb 25, 2025 at 02:20:48PM +0900, Michael Paquier wrote: > With more tweaks applied to the docs, the attached is my result. Resending once as there was a blip with the prefixes used with format-patch, preventing git am to work by default. -- Michael From 196f84b8bd8f817b6e21e65de90464d32a2

Re: Change GUC hashtable to use simplehash?

On 25.02.2025 06:55, John Naylor wrote: On Sat, Feb 15, 2025 at 12:28 PM John Naylor wrote: On Fri, Feb 14, 2025 at 6:40 PM Anton A. Melnikov wrote: Yes, of course. I tested this patch on the current master at 9e17ac997 in the same way and found no valgrind errors. Thanks, I'll push next

Re: Virtual generated columns

On Mon, Feb 24, 2025 at 9:07 PM Dean Rasheed wrote: > On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote: > > Here are the updated patches with revised comments and some tweaks to > > the commit messages. I plan to push them in one or two days. > LGTM. Pushed. Thanks all for working on this issu

Re: Add Pipelining support in psql

On Tue, Feb 25, 2025 at 2:11 AM Michael Paquier wrote: > For the prompt part, I have added a > couple of tests with \echo and the variables. The patch felt > incomplete without these. Perhaps we could extend them more, at least > we have a start point. Good catch. I guess that's also another be

Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

On Fri, Feb 21, 2025 at 2:24 PM Amit Kapila wrote: > > On Fri, Feb 21, 2025 at 7:57 AM Ajin Cherian wrote: > > In these tests, I also see an increased performance with the patch > > even when all transactions are published. I will investigate why this > > happens and update. > > > > Yes, it is im

Re: Trigger more frequent autovacuums of heavy insert tables

Hi Melanie > relallvisible. It seems like we should make it consistent. Perhaps we > should just remove it from heap_vacuum_rel(). Then add an assert in > all these places to at least protect development mistakes. I think there's some objection to that. Thanks On Tue, Feb 25, 2025 at 7:35 AM Mel

RE: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

> 03. > ``` > if (IsToastRelation(relation)) > { > Oid real_reloid = InvalidOid; > char *toast_name = > RelationGetRelationName(relation); > /* pg_toast_ len is 9 */ > char *s

Fix untranslatable split message

Hello, The recent commit 1aab6805919 introduced a help description that was split into two printf() commands, making it untranslatable. The attached patch merges them into a single message. regards. -- Kyotaro Horiguchi NTT Open Source Software Center >From f946b02bbb4e30bc250bf7386556c970ddb7

Re: Test to dump and restore objects left behind by regression

On Tue, Feb 11, 2025 at 5:53 PM Ashutosh Bapat wrote: > > Hi Michael, > > > On Sun, Feb 9, 2025 at 1:25 PM Michael Paquier wrote: > > > > On Fri, Feb 07, 2025 at 07:11:25AM +0900, Michael Paquier wrote: > > > Okay, thanks for the feedback. We have been relying on diff -u for > > > the parts of t

Statistics Import and Export commit related issue.

hi. the thread "Statistics Import and Export" is quite hot. so a new thread for some minor issue i found. static int _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH) { if (strcmp(te->desc, "STATISTICS DATA") == 0) { if (!ropt->dumpStatistics) r

Re: per backend WAL statistics

On Mon, Feb 24, 2025 at 09:07:39AM +, Bertrand Drouvot wrote: > Now that 2421e9a51d2 is in, let's resume working in this thread. PFA a rebase > to > make the CF bot happy. Nothing has changed since V7, V8 only removes > "v7-0001" ( > as part of 2421e9a51d2), so that v8-000N is nothing but v7-

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On Fri, Feb 21, 2025 at 6:25 PM Alvaro Herrera wrote: > > On 2025-Feb-21, Ashutosh Bapat wrote: > > > If I apply your patches, build binaries, I see failure. I reverted > > your patches, built binaries, I don't see failure. I apply your > > patches again, built binaries, it fails again. > > I can'

Re: Experimental tool to explore commitfest patches

> We have been trying to come up with a similar feature for the new commitfest app > I would love to help you out in porting this to the commitfest app. Great! There is plenty of work to do, there is some discussion in the discord [0]. I think it would also be nice to set up a proper data pipelin

Re: explain analyze rows=%.0f

On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov wrote: > If no one is concerned about rows being a non-integer, then I support > this, as it's quite strange for the average rows to be an integer only > for me. If we go with this approach, we should also update all examples > in the documentation a

Re: Statistics Import and Export

On Mon, 2025-02-24 at 13:47 -0500, Corey Huinker wrote: > There doesn't seem to be any way around it, but it will > slightly complicate the dump-ing side of things, in that we need to > either: > > a) switch to attnums for index expressions and keep attname calls for > everything else. The only s

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Feb 24, 2025 at 12:30 PM Andres Freund wrote: > If you need to handle the race it you need to combine it with something > additional, e.g. the so called "self pipe trick". Which e.g. the latch / wait > event set code does. Right; I'm just used to that trick being deployed in massively pa

Re: BitmapHeapScan streaming read user and prelim refactoring

On Mon, Feb 24, 2025 at 11:18 AM Melanie Plageman wrote: > > I changed my mind. I think since the struct I added was only used for > tbm_extract_page_tuple(), it was a bit weird. I also think it is okay > for callers to use TBM_MAX_TUPLES_PER_PAGE. I ended up revising this > to use the same API yo

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 4:07 PM Jeff Davis wrote: > On Mon, 2025-02-24 at 15:40 -0500, Tom Lane wrote: > > I'm a little suspicious whether that has any effect if you insert it > > before set_pglocale_pgservice(). > > Ah, right. Corey, can you please include that (in the right place, of > course)

Re: pgbench client-side performance issue on large scripts

"Daniel Verite" writes: > On large scripts, pgbench happens to consume a lot of CPU time. > For instance, with a script consisting of 5 "SELECT 1;" > I see "pgbench -f 50k-select.sql" taking about 5.8 secs of CPU time, > out of a total time of 6.7 secs. When run with perf, this profile shows u

Re: Statistics Import and Export

On Mon, 2025-02-24 at 15:03 -0500, Tom Lane wrote: > Jeff Davis writes: > > But you have a point in that float4in() does slightly more work > > than > > strtof() to handle platform differences about NaN/Inf. I'm not sure > > how > > much to weigh that concern, but I agree that there is non-zero >

Re: Statistics Import and Export

Jeff Davis writes: > But you have a point in that float4in() does slightly more work than > strtof() to handle platform differences about NaN/Inf. I'm not sure how > much to weigh that concern, but I agree that there is non-zero > cognitive overhead here. If we're speaking strictly about the relt

Re: PATCH: warn about, and deprecate, clear text passwords

On Mon, 24 Feb 2025 at 15:47, Nathan Bossart wrote: This is perhaps a nitpick, but one issue with ERROR-ing for clear text > passwords is that the default logging settings seem to send the statement > to the logs, too. So, it might actually increase the likelihood of the > password showing up in

Re: Statistics Import and Export

On Mon, 2025-02-24 at 15:40 -0500, Tom Lane wrote: > I'm a little suspicious whether that has any effect if you insert it > before set_pglocale_pgservice(). Ah, right. Corey, can you please include that (in the right place, of course) to the next iteration of your 0001 patch, if it's doing the con

Re: PATCH: warn about, and deprecate, clear text passwords

On Mon, Feb 24, 2025 at 04:06:41PM -0500, Isaac Morland wrote: > And in any case I believe the existing behaviour can still be had by > configuration so we're not really imposing anything on anybody. Well, the discussion upthread suggests "disallowing plain text passwords completely" [0], which me

Re: Statistics Import and Export

I wrote: > Hmm ... I was thinking we had it already for ALTER INDEX SET > STATISTICS, but I see that is depending on some quite ad-hoc > code (look for indstatcols and indstatvals in pg_dump.c). > I wonder if we could generalize that a bit and share the > work with this case. Those array_agg calls

Re: Statistics Import and Export

> > > > After a bit of playing around, it seemed messy to make it into > a join, but we could replace the two array_agg sub-selects with > a single one: > > (SELECT pg_catalog.array_agg(ROW(attname, attstattarget) ORDER BY attnum) > FROM pg_catalog.pg_attribute WHERE attrelid = i.indexrelid) > > a

Re: Statistics Import and Export

Hi, On February 24, 2025 10:30:08 PM GMT+01:00, Corey Huinker wrote: >From what I can see, it doesn't. Moreover, the attstattarget array agg is >only done in version 11 and higher, and we need to go as far back as we've >got expression indexes. I don't think we have to at all. It's perfectly re

Re: Add Option To Check All Addresses For Matching target_session_attr

The previous patch had a mistake in a reference in the documentation. This should fix it. On Mon, Feb 24, 2025 at 10:07 AM Andrew Jackson wrote: > Looks like this needed another rebase to account for the oauth commit. > Rebase attached. > > On Mon, Feb 24, 2025 at 9:38 AM Andrew Jackson > wrote

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 12:51 PM Tom Lane wrote: > Andres Freund writes: > > On 2025-02-24 05:11:48 -0500, Corey Huinker wrote: > >> * relpages/reltuples/relallvisible are now char[32] buffers in > RelStatsInfo > >> and nowhere else (existing relpages conversion remains, however) > > > I don't s

Re: Experimental tool to explore commitfest patches

On Sun, Feb 23, 2025 at 10:31 PM Jacob Brazeal wrote: > I have created an experimental tool [0] to help explore the vast depths of > the upcoming commitfest, and it's designed to help each contributor find > actually useful and relevant patches to review. Please have a look! As I also mentioned

Re: Statistics Import and Export

Jeff Davis writes: > There actually is a concern here, in that the backend always has > LC_NUMERIC=C when doing float4in/out, but pg_dump does not. Hmm ... interesting point, but does it matter? I think we always use our own sprintf even in frontend, and it doesn't react to LC_NUMERIC. I guess a

Re: Statistics Import and Export

> > > > I suspect that this is a *really* bad idea. It's very very hard to get > inplace > updates right. We have several unfixed correctness bugs that are related to > the use of inplace updates. I really don't think it's wise to add > additional > interfaces that can reach inplace updates unless

Re: PATCH: warn about, and deprecate, clear text passwords

On Mon, Feb 24, 2025 at 09:26:07AM -0500, Greg Sabino Mullane wrote: > * Lay the groundwork for eventually disallowing plain text passwords > completely. A long way off, but this is the start. After a couple years, we > could switch the default from "warn" to "disallow". A few years after that, > d

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 2:36 PM Tom Lane wrote: > Corey Huinker writes: > > Sadly, that attnum isn't available in pg_stats, so we'd have to > reintroduce > > the joins to pg_namespace and pg_class to get at pg_attribute, at least > for > > indexes. > > This argument seems to be made still from t

Re: Statistics Import and Export

Hi, On 2025-02-24 15:45:10 -0500, Corey Huinker wrote: > > > > > > > > I suspect that this is a *really* bad idea. It's very very hard to get > > inplace > > updates right. We have several unfixed correctness bugs that are related to > > the use of inplace updates. I really don't think it's wise

Re: Statistics Import and Export

Corey Huinker writes: > On Mon, Feb 24, 2025 at 2:36 PM Tom Lane wrote: >> ... pg_dump has all that info at >> hand; there is no need to re-query the server for it. > I went looking just now, and I can't find it. I see where we have attname > and attnum arrays for tables, but not indexes. We kee

Re: Statistics Import and Export

On Mon, 2025-02-24 at 15:53 -0500, Andres Freund wrote: > I don't think that's necessarily true, hot pruning might help some, > as afaict > the restore happens in multiple transactions. Yeah, I just dumped and reloaded the regression database with and without stats, and saw no difference in the re

Re: Statistics Import and Export

> > I don't think that's necessarily true, hot pruning might help some, as > afaict > the restore happens in multiple transactions. > If we're willing to take the potential bloat to avoid a nasty complexity, then I'm all for discarding it. Jeff just indicated off-list that he isn't seeing noticeab

Re: Restrict copying of invalidated replication slots

On Mon, Feb 24, 2025 at 3:06 AM Shlok Kyal wrote: > > On Sat, 22 Feb 2025 at 04:49, Masahiko Sawada wrote: > > > > On Fri, Feb 21, 2025 at 4:30 AM Shlok Kyal wrote: > > > > > > On Fri, 21 Feb 2025 at 01:14, Masahiko Sawada > > > wrote: > > > > > > > > On Wed, Feb 19, 2025 at 3:46 AM Shlok Kyal

Re: Statistics Import and Export

Jeff Davis writes: > We certainly want attnames for tables to keep it working reasonably > well for cases where the user might be doing something more interesting > than a binary upgrade, as you point out. But attribute numbers for > indexes seem much more reliable: an index with a different attri

Re: Statistics Import and Export

Corey Huinker writes: > Sadly, that attnum isn't available in pg_stats, so we'd have to reintroduce > the joins to pg_namespace and pg_class to get at pg_attribute, at least for > indexes. This argument seems to be made still from the mindset that you are going to form a query that produces exact

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Mon, Feb 24, 2025 at 7:13 AM Bertrand Drouvot wrote: > > Hi, > > On Mon, Feb 24, 2025 at 05:01:30PM +0530, Amit Kapila wrote: > > On Wed, Feb 12, 2025 at 5:22 PM Amit Kapila wrote: > > > > > > On Wed, Feb 12, 2025 at 1:16 AM Masahiko Sawada > > > wrote: > > > > > > > > > > > > Agreed, I'm fi

Re: PATCH: warn about, and deprecate, clear text passwords

On 24/02/2025 14:55, Greg Sabino Mullane wrote: Guillaume Lelarge > wrote: I'm obviously +1 on this patch since I sent kinda the same patch two weeks ago Ha ha, my brain forgot about that one (even though I commented on it!) - apologies for that.

Re: Statistics Import and Export

On Mon, 2025-02-24 at 12:57 -0500, Corey Huinker wrote: > As I see it, the point is that we're getting an input that is a > string representation from the query, and the end-goal is to convey > that value with fidelity to the destination database, so there's > nothing we can do to get us closer to

Re: MAX_BACKENDS size (comment accuracy)

The recent commits for this drew my attention to the comment for MAX_BACKENDS. Specifically, it says we check the value in RegisterBackgroundWorker() (which appears to have been untrue since we added max_worker_processes) and relevant GUC check hooks (which I removed last year in commit 0b1fe14).

Securing PostgreSQL for rootless containers

Hello Hackers, When running PostgreSQL in container as rootless and bridged network, all connection will appear as local connection not matter what their origin is and pg_hba.conf based allow/deny will not be effective. One approach is to make PostgreSQL aware of systemd socket activation, w

pgbench client-side performance issue on large scripts

Hi, On large scripts, pgbench happens to consume a lot of CPU time. For instance, with a script consisting of 5 "SELECT 1;" I see "pgbench -f 50k-select.sql" taking about 5.8 secs of CPU time, out of a total time of 6.7 secs. When run with perf, this profile shows up: 81,10% pgbench pgben

Re: proposal - plpgsql - support standard syntax for named arguments for cursors

Review: This patch claims to add SQL/PSM named arguments syntax to cursors and this what it does exactly.  It compiles without error with master current code and all tests passed successfully. I think it could be ready to be committed. Note for the committer: does it make sense to mention

Re: Serverside SNI support in libpq

On Wed, Feb 19, 2025 at 3:13 PM Daniel Gustafsson wrote: > Are there any blockers for getting this in? > + SSL_context = ssl_init_context(isServerStart, host); I'm still not quite following the rationale behind the SSL_context assignment. To maybe illustrate, attached are some tests th

Re: Statistics Import and Export

> On 24 Feb 2025, at 22:33, Andres Freund wrote: > I'd go even so far to say that it's a bad idea to support unsupported source > versions, because it'll mean we'll practically get very very little testing > for those paths but claim to support them. +1. Maintaining pg_upgrade is hard enough

Re: Trigger more frequent autovacuums of heavy insert tables

On Thu, Feb 20, 2025 at 07:35:32PM -0500, Melanie Plageman wrote: > Attache v7 doesn't cap the result for manual stats updating done with > relation_statistics_update(). Unfortunately, this already needs a rebase... > I did, however, keep the cap for the > places where vacuum/analyze/create index

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 4:33 PM Andres Freund wrote: > Hi, > > On February 24, 2025 10:30:08 PM GMT+01:00, Corey Huinker < > corey.huin...@gmail.com> wrote: > >From what I can see, it doesn't. Moreover, the attstattarget array agg is > >only done in version 11 and higher, and we need to go as far

Re: Statistics Import and Export

On Mon, 2025-02-24 at 12:50 -0500, Tom Lane wrote: > Also, while working on the attached, I couldn't help forming the > opinion that we'd be better off to nuke pg_set_attribute_stats() > from orbit and require people to use pg_restore_attribute_stats(). I had intended the pg_set variants to be use

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 1:54 PM Jeff Davis wrote: > On Mon, 2025-02-24 at 13:47 -0500, Corey Huinker wrote: > > There doesn't seem to be any way around it, but it will > > slightly complicate the dump-ing side of things, in that we need to > > either: > > > > a) switch to attnums for index expres

Re: [PoC] Federated Authn/z with OAUTHBEARER

Hi, On 2025-02-24 09:39:52 -0800, Jacob Champion wrote: > On Fri, Feb 21, 2025 at 9:19 AM Andres Freund wrote: > > And, probably worse, isn't relying on getting EINTR rather racy, due to the > > chance of the signal arriving between CHECK_FOR_INTERRUPTS() and the > > blocking > > system call? >

Re: pgbench client-side performance issue on large scripts

I wrote: > Yeah, we do rely on yylineno in bootscanner.l and ecpg, but not > elsewhere; not sure if there's a performance reason for that. Ah: the flex manual specifically calls out "%option yylineno" as something that has a moderate performance cost. So that's why we don't use it except in non-p

Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators

On Tue, Feb 11, 2025 at 2:04 PM Jeff Davis wrote: > ... > Storing work_mem in each Plan node, and using that to enforce the > memory limit (rather than using the GUC directly), seems > uncontroversial to me. I'd suggest a standalone patch. I will submit a patch for this, thanks. (This will be "Pa

Re: Parallel heap vacuum

On Mon, Feb 17, 2025 at 12:11 PM Masahiko Sawada wrote: > > If the idea is to never allow parallelism in vacuum, then I think > > disabling eager scanning during manual parallel vacuum seems > > reasonable. People could use vacuum freeze if they want more freezing. > > IIUC the purpose of paralle

Re: Statistics Import and Export

Hi, On 2025-02-24 13:47:19 -0500, Corey Huinker wrote: > and the "restore" family has the following properties: > > 1. will inplace update pg_class to avoid table bloat I suspect that this is a *really* bad idea. It's very very hard to get inplace updates right. We have several unfixed correctne

Re: MAX_BACKENDS size (comment accuracy)

Hi, On 2025-02-24 13:52:51 -0600, Nathan Bossart wrote: > The recent commits for this drew my attention to the comment for > MAX_BACKENDS. Specifically, it says we check the value in > RegisterBackgroundWorker() (which appears to have been untrue since we > added max_worker_processes) and relevan

Re: Statistics Import and Export

On Mon, 2025-02-24 at 15:36 -0500, Andres Freund wrote: > > 1. will inplace update pg_class to avoid table bloat > > I suspect that this is a *really* bad idea. The reason we added it is that it's what ANALYZE does, and a big restore bloats pg_class without it. I don't think those are major conc

RE: Improve CRC32C performance on SSE4.2

> Here's another idea to make it more automatic: Give up on initializing every > capability at once. I'm not sure I like giving up this. Initializing and running CPUID check with the attribute constructor is very valuable for two reasons: (1) you get everything done at load time before main and

Re: MAX_BACKENDS size (comment accuracy)

On Mon, Feb 24, 2025 at 03:38:24PM -0500, Andres Freund wrote: > Makes sense. Committed, thanks. -- nathan

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 10:51:34PM +0100, Daniel Gustafsson wrote: >> On 24 Feb 2025, at 22:33, Andres Freund wrote: > >> I'd go even so far to say that it's a bad idea to support unsupported >> source versions, because it'll mean we'll practically get very very >> little testing for those paths

Re: Statistics Import and Export

On Mon, Feb 24, 2025 at 4:30 PM Corey Huinker wrote: > >> >> After a bit of playing around, it seemed messy to make it into >> a join, but we could replace the two array_agg sub-selects with >> a single one: >> >> (SELECT pg_catalog.array_agg(ROW(attname, attstattarget) ORDER BY attnum) >> FROM

Re: Trigger more frequent autovacuums of heavy insert tables

On Mon, Feb 24, 2025 at 4:53 PM Nathan Bossart wrote: > > On Thu, Feb 20, 2025 at 07:35:32PM -0500, Melanie Plageman wrote: > > Attache v7 doesn't cap the result for manual stats updating done with > > relation_statistics_update(). > > Unfortunately, this already needs a rebase... Thanks! Attache

Re: Fix logging for invalid recovery timeline

On Mon, Feb 24, 2025 at 05:30:35PM +, David Steele wrote: > +/* translator: %s is a backup_label or > pg_control file */ See for example PostmasterMain() with the "/* translator: %s is a configuration file */". > + errdetail("Latest checkpoint in %s

Re: Parallel heap vacuum

On Sun, Feb 23, 2025 at 8:51 PM John Naylor wrote: > > On Tue, Feb 18, 2025 at 1:11 AM Masahiko Sawada wrote: > > > > Right. I'm inclined to support only the second heap pass as the first > > step. If we support parallelism only for the second pass, it cannot > > help speed up freezing the entire

RE: pg_recvlogical requires -d but not described on the documentation

Dear Ashutosh, Thanks for the confirmation! > This looks good to me. It builds with meson. Didn't check make. I confirmed it could be built via make command. > > Hmm, unify the treatment seems clean, but it may break current connection > rules > > for some application. I'm not sure now this is

Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators

On Mon, 2025-02-24 at 12:46 -0800, James Hunter wrote: > Attached please find the patch set I mentioned, above, in [1]. It > consists of 4 patches that serve as the building blocks for and a > prototype of the "query_work_mem" GUC I proposed: I didn't look at the details yet. But from: https://ww

Re: Add Pipelining support in psql

On Fri, Feb 21, 2025 at 11:33:41AM +0900, Michael Paquier wrote: > Attached are the remaining pieces, split here because they are > different bullet points: > - Tests for implicit transactions with various commands, with some > edits. > - Prompt support, with more edits. > > I'm putting these on

Re: generic plans and "initial" pruning

On Sun, Feb 23, 2025 at 9:46 PM Tender Wang wrote: > Amit Langote 于2025年2月23日周日 16:36写道： >> On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote: >> > Alexander Lakhin 于2025年2月22日周六 23:00写道： >> >> Please look at new error, produced by the following script, >> >> starting from 525392d57: >> >> CREA

Re: PATCH: warn about, and deprecate, clear text passwords

On Mon, Feb 24, 2025 at 4:18 PM Nathan Bossart wrote: > Well, the discussion upthread suggests "disallowing plain text passwords > completely" Yeah, that's more of a long-term dream than a real plan. It would certainly be no sooner than Postgres v24 or so... Cheers, Greg -- Crunchy Data - htt

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Mon, Feb 24, 2025 at 11:39 AM Masahiko Sawada wrote: > > On Mon, Feb 24, 2025 at 7:13 AM Bertrand Drouvot > wrote: > > > > Hi, > > > > On Mon, Feb 24, 2025 at 05:01:30PM +0530, Amit Kapila wrote: > > > On Wed, Feb 12, 2025 at 5:22 PM Amit Kapila > > > wrote: > > > > > > > > On Wed, Feb 12, 2

Re: Statistics Import and Export

On Mon, 2025-02-24 at 17:26 -0500, Corey Huinker wrote: > Digging some more on this, I see that we populate indxinfo[j].indkey > as if it's an array of Oids, It looks like it's done that way so that parseOidArray() can be used. A hack, I suppose, but makes some sense to reuse that code. We should

Re: Update docs for UUID data type

Please find the attached patch, which only addresses the UUID functions (in table format). I appreciate the comments related to the UUID datatype. If you feel like the additional content didn't add clarity, I certainly won't argue. Best regards, Andy Alsup On Mon, Feb 24, 2025 at 2:02 AM Laurenz

Re: psql \dh: List High-Level (Root) Tables and Indexes

Dear all, I'm grateful for taking your time and providing various solutions! Personally, I like Tom's idea of using N better: * It can stand for "not a partition member" or "no partitions", and does not provide any new terminology. * It can be combined with various commands \dN, \dtN (or \dNt),

Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing

Hi, On Mon, Feb 24, 2025 at 09:57:49AM +0900, Michael Paquier wrote: > On Thu, Feb 20, 2025 at 08:11:12AM +, Bertrand Drouvot wrote: > > LGTM. > > Applied this one. Thanks! > Now, to the part about the backend stats and WAL, > which should be the last piece.. Yup, going back to [1] now. [

Re: [PoC] Federated Authn/z with OAUTHBEARER

> On 24 Feb 2025, at 00:45, Daniel Gustafsson wrote: > The attached diff passes CI and works for me, will revisit in the morning. Dave reported (on Discord) that the OPTIONAL macro collided with windef.h, so attached is a small fix for that as well (even though we don't support Windows here righ

Re: per backend WAL statistics

Hi, On Wed, Feb 19, 2025 at 07:28:49AM +0900, Michael Paquier wrote: > On Tue, Feb 18, 2025 at 10:45:29AM +, Bertrand Drouvot wrote: > > Agree, done that way in the dedicated thread ([1]). > > > > [1]: > > https://www.postgresql.org/message-id/flat/Z7RkQ0EfYaqqjgz/%40ip-10-97-1-34.eu-west-3.

Re: Non-text mode for pg_dumpall

hi. some documentation issue: doc/src/sgml/ref/pg_dumpall.sgml d directory Output a directory-format archive suitable for input into pg_restore. Under dboid subdirectory, this will create a directory with one file for ea

Re: Virtual generated columns

On Mon, Feb 24, 2025 at 3:50 PM jian he wrote: > On Sat, Feb 22, 2025 at 11:12 PM Richard Guo wrote: > > On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote: > > > Attached are the updated patches to fix all the mentioned issues. I > > > plan to push them early next week after staring at the cod

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Mon, Feb 24, 2025 at 10:57 AM Amit Kapila wrote: > > On Tue, Feb 18, 2025 at 12:16 AM Shubham Khanna > wrote: > > > > -static void check_publisher(const struct LogicalRepInfo *dbinfo); > -static char *setup_publisher(struct LogicalRepInfo *dbinfo); > +static void check_publisher(const struct L

Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing

Hi, On 2025-02-20 14:37:18 +0900, Michael Paquier wrote: > a051e71e28a added this information into pg_stat_io (with more details and > granularity), so there is no need to keep it in pg_stat_wal. This also > allows to remove PendingWalStats and simplifies up coming commits related > to per backend

Re: long-standing data loss bug in initial sync of logical replication

On Wed, Dec 11, 2024 at 12:37 PM Masahiko Sawada wrote: > > I confirmed that the proposed patch fixes these issues. I have one > question about the patch: > > In the main loop in SnapBuildDistributeSnapshotAndInval(), we have the > following code: > >/* > * If we don't have a base

Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup

On Thu Feb 20, 2025 at 1:37 AM CET, Andres Freund wrote: I've pushed this, with one trivial modification: I added %m to the error message in case setrlimit() fails. That's really unlikely to ever happen, but ... Great! Attached are the updated other patches, I think I addressed all feedback. Fr

Re: PATCH: warn about, and deprecate, clear text passwords

Hi, > There have been a few complaints lately about the fact that we cavalierly > allow clear text passwords to be sent when doing CREATE USER or ALTER USER. > These, of course, can end up in many places, such as pg_stat_activity, > pg_stat_statements, .psql_history, and the server logs. It is

Re: Statistics Import and Export

> > That's a good point but let's avoid excessive redundancy in the > structures. Adding a few fields to RelStatsInfo should be enough. > > Regards, > Jeff Davis > Incorporating most of the feedback (I kept a few of the appendNamedArgument() calls) presented over the weekend. * removeVer

Flaky 003_start_stop.pl test

The test introduced in bb86141 turns out to be flaky in CI[1] with the following error message: [03:40:43.047] stderr: [03:40:43.047] # Failed test 'connect : matches' [03:40:43.047] # at /tmp/cirrus-ci-build/src/test/postmaster/t/003_start_stop.pl line 78. [03:40:43.047] # 'psql: error: connectio

  1   2   >