Re: SQL:2011 application time

On 15.05.24 11:39, Peter Eisentraut wrote: Attached are the individual revert patches.  I'm supplying these here mainly so that future efforts can use those instead of the original patches, since that would have to redo all the conflict resolution and also miss various typo fixes etc. that were

Re: Docs: Always use true|false instead of sometimes on|off for the subscription options

On Thu, May 16, 2024 at 3:11 PM David Rowley wrote: > > On Thu, 16 May 2024 at 12:29, Peter Smith wrote: > > There are lots of subscription options listed on the CREATE > > SUBSCRIPTION page [1]. > > > > Although these boolean options are capable of accepting different > > values like "1|0", "on|

Minor cleanups in the SSL tests

When writing a new SSL test for another patch it struck me that the SSL tests are doing configuration management without using the test framework API's. The attached patches cleans this up, no testcases are altered as part of this. 0001 makes the test for PG_TEST_EXTRA a top-level if statement no

Re: POC: GROUP BY optimization

On 24.04.2024 13:25, jian he wrote: hi. I found an interesting case. CREATE TABLE t1 AS SELECT (i % 10)::numeric AS x,(i % 10)::int8 AS y,'abc' || i % 10 AS z, i::int4 AS w FROM generate_series(1, 100) AS i; CREATE INDEX t1_x_y_idx ON t1 (x, y); ANALYZE t1; SET enable_hashagg = off; SET en

Re: First draft of PG 17 release notes

On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote: > > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html > >> Add jsonpath methods to convert JSON values to different data types (Jeevan >> Cha

Re: Postgres and --config-file option

Hi, > Agreed that mentioning the --name variant is useful. I'm not really > on board with having one option refer to the other on the pages where > both are described, like on --help or the doc page for "postgres". > > For now, I've applied a patch for the libpq.sgml and config.sgml bits > which

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

On Wed, 2024-05-15 at 14:39 -0400, Tom Lane wrote: > The thing that was bothering me most about this is that I don't > understand why that's a useful check.  If I meant to type > > UPDATE mytab SET mycol = 42; > > and instead I type > > UPDATEE mytab SET mycol = 42; > > your propose

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 5 Apr 2024 at 18:30, Dave Cramer wrote: > On Fri, 5 Apr 2024 at 12:09, Jelte Fennema-Nio wrote: >> I'll take a look at redesigning the protocol parameter stuff. To work >> with dedicated functions instead. > > +1 It's been a while, but I now actually took the time to look into this. And

Re: Statistics Import and Export

> > Can you explain what you did with the > SECTION_NONE/SECTION_DATA/SECTION_POST_DATA over v19-v21 and why? > Initially, I got things to work by having statistics import behave like COMMENTs, which meant that they were run immediately after the table/matview/index/constraint that created the pg_

Re: Minor cleanups in the SSL tests

On 16.05.24 09:24, Daniel Gustafsson wrote: When writing a new SSL test for another patch it struck me that the SSL tests are doing configuration management without using the test framework API's. The attached patches cleans this up, no testcases are altered as part of this. 0001 makes the test

Re: Wrong results with grouping sets

On Sun, Jan 7, 2024 at 4:59 AM Tom Lane wrote: > I don't think this is going in quite the right direction. We have > many serious problems with grouping sets (latest one today at [1]), > and I don't believe that hacking around EquivalenceClasses is going > to fix them all. > > I think that what

Re: First draft of PG 17 release notes

On Thu, 16 May 2024 at 05:48, Andres Freund wrote: > We're having this debate every release. I think the ongoing reticence to note > performance improvements in the release notes is hurting Postgres. > > For one, performance improvements are one of the prime reason users > upgrade. Without them be

Re: A wrong comment about search_indexed_tlist_for_var

On Wed, May 15, 2024 at 1:07 AM Robert Haas wrote: > On Mon, Dec 4, 2023 at 3:42 AM Richard Guo wrote: > > Then here is a trivial patch to adjust the comment, which should get > > reverted along with 867be9c07. > > Richard, since you're a committer now, maybe you'd like to commit > this. I don't

Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block

On 2024/5/16 00:58, Robert Haas wrote: On Tue, Apr 16, 2024 at 3:16 AM Quan Zongliang wrote: According to the discussion with Jian He. Use the guc hook to check if the xid needs to be output. If needed, the statement log can be delayed to be output. I appreciate the work that both of you h

Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

On 16.05.24 01:32, Tom Lane wrote: As for the remainder, they aren't showing up because no variable or field is declared using them, which means no debug symbol table entry is made for them. This means we could just drop those typedefs and be little the worse off notationally. I experimented wi

Re: An improved README experience for PostgreSQL

On 15.05.24 21:34, Nathan Bossart wrote: On Wed, May 15, 2024 at 07:23:19AM +0200, Peter Eisentraut wrote: I think for CONTRIBUTING.md, a better link would be . WFM This patch version looks good to me.

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

On 15.05.24 21:05, Robert Haas wrote: I don't think it's at all obvious that this belongs on the server side rather than the client side. I think it could be done in either place, or both. I just think we don't have the infrastructure to do it cleanly, at present. I think if you're going to do

Re: PostgreSQL 17 Beta 1 release announcement draft

On Thu, 16 May 2024 at 03:45, Jonathan S. Katz wrote: > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement > draft. I think we can quickly mention c4ab7da6061 in the COPY paragraph, in some benchmarks it improved perf by close to 2x. Something like this: "has improved performance

Re: Why is parula failing?

On Tue, 14 May 2024 at 08:55, David Rowley wrote: > I've not seen any recent failures from Parula that relate to this > issue. The last one seems to have been about 4 weeks ago. > > I'm now wondering if it's time to revert the debugging code added in > 1db689715. Does anyone think differently?

Re: GUC names in messages

On 04.01.24 07:53, Peter Smith wrote: Now that I read this again, I think this is wrong. We should decide the quoting for a category, not the actual content. Like, quote all file names; do not quote keywords. This led to the attempted patch to decide the quoting of GUC parameter names dynamical

Re: Adding the extension name to EData / log_line_prefix

On 15.05.24 17:50, Tom Lane wrote: We kind of already have something like this, for NLS. If you look for pg_bindtextdomain(TEXTDOMAIN) and ereport_domain(), this information already trickles into the vicinity of the error data. Maybe the same thing could just be used for this, by wiring up the

Re: GUC names in messages

On 2024-May-16, Peter Eisentraut wrote: > I think we should accept your two patches > > v6-0001-GUC-names-docs.patch > v6-0002-GUC-names-add-quotes.patch > > which effectively everyone was in favor of and which seem to be the most > robust and sustainable solution. I think we should also take p

Re: Why is citext/regress failing on hamerkop?

Hello Thomas, 16.05.2024 04:32, Thomas Munro wrote: On Thu, May 16, 2024 at 10:43 AM Thomas Munro wrote: Any chance you could test this version please Alexander? Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI thing and is superficially better, but it doesn't handle code th

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/15/24 21:45, Jonathan S. Katz wrote: Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the beta release takes some extra effort, I want to ensure all changes are in with time to spare before release day. "You can find information about all of the features and changes found

Re: First draft of PG 17 release notes

On 5/15/24 23:48, Andres Freund wrote: On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote: I disagree with this. IMO the impact of the Sawada/Naylor change is likely to be enormous for people with large tables and large numbers of tuples to clean up (I know we've had a number of customers in th

Re: CREATE DATABASE with filesystem cloning

Hi, On Thu, 9 May 2024 at 19:29, Robert Haas wrote: > > On Wed, May 8, 2024 at 10:34 AM Nazir Bilal Yavuz wrote: > > > I'm not so sure about the GUC name. On the one hand, it feels like > > > createdb should be spelled out as create_database, but on the other > > > hand, the GUC name is quite lo

Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block

On Thu, May 16, 2024 at 6:01 AM Quan Zongliang wrote: > I thought about writing statement log when xid assigned. But it's seemed > too complicated. > I'm inclined to keep it for a while. Until we find a good way or give > up. It's a reasonable request, after all. I don't think it's reasonable at

Re: CREATE DATABASE with filesystem cloning

On Thu, May 16, 2024 at 8:35 AM Nazir Bilal Yavuz wrote: > I updated the documentation and put a comment on top of the copydir() > function to inform that further changes and uses of this function may > require documentation updates. I was assuming that the documentation for the file_copy_method

Re: Docs: Always use true|false instead of sometimes on|off for the subscription options

On Thu, 16 May 2024 at 19:05, Peter Smith wrote: > > On Thu, May 16, 2024 at 3:11 PM David Rowley wrote: > > If you want to do this, what's the reason to limit it to just this one > > page of the docs? > > Yeah, I had a vested interest in this one place because I've been > reviewing the other thr

Re: A wrong comment about search_indexed_tlist_for_var

On Thu, May 16, 2024 at 5:58 AM Richard Guo wrote: > Thank you for the suggestion. Yeah, this is a good candidate for my > first commit. :-) I will aim to do it during the next commitfest. You don't need to wait for the next CommitFest to fix a comment (or a bug). And, indeed, it's better if yo

Re: [DOC] Add detail regarding resource consumption wrt max_connections

On Wed, May 15, 2024 at 4:22 PM Robert Treat wrote: > Nope. Let's do the best bang for the buck improvement and we can see > if we get any feedback that indicates more needs to be done. Done. -- Robert Haas EDB: http://www.enterprisedb.com

Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 11:48 PM Andres Freund wrote: > > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote: > > I disagree with this. IMO the impact of the Sawada/Naylor change is > > likely to be enormous for people with large tables and large numbers of > > tuples to clean up (I know we've ha

Re: libpq compression (part 3)

On Wed, May 15, 2024 at 12:50 PM Jacob Burroughs wrote: > I think I would agree with that. That said, I don't think the client > should be in the business of specifying what configuration of the > compression algorithm the server should use. The server administrator > (or really most of the time

Re: Pre-Commitfest Party on StHighload conf

Hi, > StHighload conference will be held on June 24-25[0]. I’m planning to do > “Pre-Commitfest Party” there. > > The idea is to help promote patches among potential reviewers. And start > working with the very beginning of PG18 development cycle. > Good patch review of a valuable feature is a g

Re: CREATE DATABASE with filesystem cloning

Hi, On Thu, 16 May 2024 at 15:40, Robert Haas wrote: > > On Thu, May 16, 2024 at 8:35 AM Nazir Bilal Yavuz wrote: > > I updated the documentation and put a comment on top of the copydir() > > function to inform that further changes and uses of this function may > > require documentation updates.

Re: Direct SSL connection with ALPN and HBA rules

On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote: > Ok, yeah, I can see that now. Here's a new version to address that. I > merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method, > ENC_SSL. The places that need to distinguish between them now check > conn-sslnegotiation.

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/16/24 08:05, Joe Conway wrote: On 5/15/24 21:45, Jonathan S. Katz wrote: Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the beta release takes some extra effort, I want to ensure all changes are in with time to spare before release day. "`EXPLAIN` can now show how much

Re: Direct SSL connection with ALPN and HBA rules

> On 16 May 2024, at 15:54, Robert Haas wrote: > > On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote: >> Ok, yeah, I can see that now. Here's a new version to address that. I >> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method, >> ENC_SSL. The places that need to d

avoid MERGE_ACTION keyword?

I wonder if we can avoid making MERGE_ACTION a keyword. I think we could parse it initially as a function and then transform it to a more special node later. In the attached patch, I'm doing this in parse analysis. We could try to do it even later and actually execute it as a function, if we

Re: AIX support

Hi Team, We have an update wrt to the PG17 AIX port. We have reverted the changes specific to AIX (that were removed in 0b16bb8776bb8) to the latest PG17 (head). The Buildfarm succeeded for these changes. All the tests passed. System config OS level : AIX-73D Compil

Re: Direct SSL connection with ALPN and HBA rules

On 16/05/2024 17:08, Daniel Gustafsson wrote: On 16 May 2024, at 15:54, Robert Haas wrote: On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote: Ok, yeah, I can see that now. Here's a new version to address that. I merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,

Re: AIX support

On 2024-May-16, Sriram RK wrote: > Hi Team, > > We have an update wrt to the PG17 AIX port. > > We have reverted the changes specific to AIX (that were removed in > 0b16bb8776bb8) to the latest PG17 (head). > > The Buildfarm succeeded for these changes. All the tests passed. Excellent. > Can

Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

Peter Eisentraut writes: > In these cases, I think for > NotificationHash > ResourceOwnerData > WalSyncMethod > we can just get rid of the typedef. I have no objection to dealing with NotificationHash as you have here. > ReadBuffersFlags shouldn't be an enum at all, because its values are > use

Re: CREATE DATABASE with filesystem cloning

On Thu, May 16, 2024 at 9:43 AM Nazir Bilal Yavuz wrote: > Actually, the documentation for the file_copy_method was mentioning > the things it controls; I converted it to an itemized list now. Also, > changed the comment to: 'Further uses of this function requires > updates to the list that GUC co

Re: Direct SSL connection with ALPN and HBA rules

On Thu, May 16, 2024 at 10:23 AM Heikki Linnakangas wrote: > Yep, committed. Thanks everyone! Thanks! -- Robert Haas EDB: http://www.enterprisedb.com

Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 11:48 PM Andres Freund wrote: > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote: > > I disagree with this. IMO the impact of the Sawada/Naylor change is > > likely to be enormous for people with large tables and large numbers of > > tuples to clean up (I know we've had

Re: Requiring LLVM 14+ in PostgreSQL 18

Hi, On Thu, 16 May 2024 at 05:34, Thomas Munro wrote: > > On Wed, May 15, 2024 at 5:20 PM Peter Eisentraut wrote: > > Yes, let's get that v3-0001 patch into PG17. > > Done. > > Bilal recently created the CI images for Debian Bookworm[1]. You can > try them with s/bullseye/bookworm/ in .cirrus.t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 5:22 AM Jelte Fennema-Nio wrote: > If we're not setting the protocol parameter in the StartupMessage, > there's currently no way for us to know if the protocol parameter is > supported by the server. If protocol parameters were unchangable then > that would be fine, but the

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

On Wed, May 15, 2024 at 8:46 AM Robert Haas wrote: > On Thu, Apr 4, 2024 at 12:41 AM Erik Wienhold wrote: > > Thanks, fixed in v4. Looks like American English prefers that comma and > > it's also more common in our docs. > > Reviewing this patch: > > - Creates a typed table, which takes it

Re: First draft of PG 17 release notes

On 2024-05-14 Tu 20:39, Bruce Momjian wrote: On Sat, May 11, 2024 at 03:32:55PM -0400, Andrew Dunstan wrote: On 2024-05-09 Th 00:03, Bruce Momjian wrote: I have committed the first draft of the PG 17 release notes; you can see the results here: https://momjian.us/pgsql_docs/release-

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 16 May 2024 at 17:29, Robert Haas wrote: > You're probably not going to like this answer, but I feel like this is > another sign that you're trying to use the protocol extensibility > facilities in the wrong way. In my first reply to the thread, I > proposed having the client send _pq_.pro

Re: race condition when writing pg_control

On Sun, Jun 7, 2020 at 10:49 PM Thomas Munro wrote: > > On Wed, Jun 3, 2020 at 2:03 PM Michael Paquier wrote: > > On Wed, Jun 03, 2020 at 10:56:13AM +1200, Thomas Munro wrote: > > > Sorry for my radio silence, I got tangled up with a couple of > > > conferences. I'm planning to look at 0001 and

Re: broken JIT support on Fedora 40

> On Tue, May 14, 2024 at 11:09:39AM -0400, Robert Haas wrote: > On Tue, Apr 9, 2024 at 8:44 PM Thomas Munro wrote: > > I pushed the illegal attribute fix though. Thanks for the detective work! > > This was commit 53c8d6c9f157f2bc8211b8de02417e55fefddbc7 and as I > understand it that fixed the is

Re: allow changing autovacuum_max_workers without restarting

>>> That's true, but using a hard-coded limit means we no longer need to add a >>> new GUC. Always allocating, say, 256 slots might require a few additional >>> kilobytes of shared memory, most of which will go unused, but that seems >>> unlikely to be a problem for the systems that will run Postgr

Re: Docs: Always use true|false instead of sometimes on|off for the subscription options

Peter Smith writes: > Yeah, I had a vested interest in this one place because I've been > reviewing the other thread [1] that was mentioned above. If that other > thread chooses "true|false" then putting "true|false" adjacent to > another "on|off" will look silly. But if that other thread adopts t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 12:09 PM Jelte Fennema-Nio wrote: > I don't really understand the benefit of your proposal over option 2 > that I proposed. Afaict you're proposing that for e.g. compression we > first set _pq_.supports_compression=1 in the StartupMessage and use > that to do feature detec

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 6:57 AM Robert Haas wrote: > > Ugh, it's so hard to communicate clearly about this stuff. I didn't > really have any thought that we'd ever try to handle something as > complicated as compression using ParameterSet. I tend to agree that > for compression I'd like to see the

Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load

Daniel Gustafsson writes: >> On 5 Jul 2022, at 18:59, Tom Lane wrote: >> Given the lack of field complaints, it's probably not worth trying >> to do anything to restore that capability. But we really ought to >> update pg_upgrade's code and docs in pre-v15 branches to say that >> the minimum sup

Re: Statistics Import and Export

On Thu, 2024-05-16 at 05:25 -0400, Corey Huinker wrote: > > Per previous comments, it was suggested by others that: > > - having them in SECTION_NONE was a grave mistake > - Everything that could belong in SECTION_DATA should, and the rest > should be in SECTION_POST_DATA I don't understand the

commitfest.postgresql.org is no longer fit for purpose

Hi, The original intent of CommitFests, and of commitfest.postgresql.org by extension, was to provide a place where patches could be registered to indicate that they needed to be reviewed, thus enabling patch authors and patch reviewers to find each other in a reasonably efficient way. I don't thi

Re: race condition when writing pg_control

On Thu, May 16, 2024 at 12:19:22PM -0400, Melanie Plageman wrote: > Today, after committing a3e6c6f, I saw recovery/018_wal_optimize.pl > fail and see this message in the replica log [2]. > > 2024-05-16 15:12:22.821 GMT [5440][not initialized] FATAL: incorrect > checksum in control file > > I'm

Re: race condition when writing pg_control

Nathan Bossart writes: > I suspect it will be difficult to investigate this one too much further > unless we can track down a copy of the control file with the bad checksum. > Other than searching for any new code that isn't doing the appropriate > locking, maybe we could search the buildfarm for

Re: race condition when writing pg_control

Hi, On 2024-05-16 14:50:50 -0400, Tom Lane wrote: > Nathan Bossart writes: > > I suspect it will be difficult to investigate this one too much further > > unless we can track down a copy of the control file with the bad checksum. > > Other than searching for any new code that isn't doing the appr

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Wed, 2024-05-15 at 16:31 -0700, Jeff Davis wrote: > Even better would be if we could take into account partitioning. That > might be out of scope for your current work, but it would be very > useful. We could have a couple new GUCs like modify_table_buffer and > modify_table_buffer_per_partition

Re: race condition when writing pg_control

Andres Freund writes: > On 2024-05-16 14:50:50 -0400, Tom Lane wrote: >> The intention was certainly always that it be atomic. If it isn't >> we have got *big* trouble. > We unfortunately do *know* that on several systems e.g. basebackup can read a > partially written control file, while the con

Re: race condition when writing pg_control

Hi, On 2024-05-16 15:01:31 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-05-16 14:50:50 -0400, Tom Lane wrote: > >> The intention was certainly always that it be atomic. If it isn't > >> we have got *big* trouble. > > > We unfortunately do *know* that on several systems e.g. baseba

Re: commitfest.postgresql.org is no longer fit for purpose

Op 5/16/24 om 20:30 schreef Robert Haas: Hi, The original intent of CommitFests, and of commitfest.postgresql.org by extension, was to provide a place where patches could be registered to indicate that they needed to be reviewed, thus enabling patch authors and patch reviewers to find each other

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 11:30 AM Robert Haas wrote: > Hi, > > The original intent of CommitFests, and of commitfest.postgresql.org > by extension, was to provide a place where patches could be registered > to indicate that they needed to be reviewed, thus enabling patch > authors and patch review

Re: commitfest.postgresql.org is no longer fit for purpose

Thanks for raising this. As someone who is only modestly familiar with Postgres internals or even C, but would still like to contribute through review, I find the current process of finding a suitable patch both tedious and daunting. The Reviewing a Patch article on the wiki [0] says reviews like m

Re: commitfest.postgresql.org is no longer fit for purpose

> On 16 May 2024, at 20:30, Robert Haas wrote: > The original intent of CommitFests, and of commitfest.postgresql.org > by extension, was to provide a place where patches could be registered > to indicate that they needed to be reviewed, thus enabling patch > authors and patch reviewers to find e

Re: commitfest.postgresql.org is no longer fit for purpose

Daniel Gustafsson writes: >> On 16 May 2024, at 20:30, Robert Haas wrote: >> The original intent of CommitFests, and of commitfest.postgresql.org >> by extension, was to provide a place where patches could be registered >> to indicate that they needed to be reviewed, thus enabling patch >> author

Re: GUC names in messages

> On 16 May 2024, at 13:35, Peter Eisentraut wrote: > I think we should accept your two patches I agree with this. > v6-0001-GUC-names-docs.patch +1 > v6-0002-GUC-names-add-quotes.patch - errmsg("WAL generated with full_page_writes=off was replayed " + errmsg("WAL generated with \"full_page_

Re: GUC names in messages

> On 16 May 2024, at 13:56, Alvaro Herrera wrote: > I think we should also take patch 0005 in pg17, which reduces the number > of strings to translate. Agreed, lessening the burden on translators is always a good idea. -- Daniel Gustafsson

Re: commitfest.postgresql.org is no longer fit for purpose

When I was CFM for a couple cycles I started with the idea that I was going to try being a hardass and rejecting or RWF all the patches that had gotten negative reviews and been bounced forward. Except when I actually went through them I didn't find many. Mostly like Robert I found perfectly reaso

gist index builds try to open FSM over and over

Hi, I built a gist index to try to test a theory in some other thread. For that the indexes need to cover a lot of entries. With gist creating the index took a long time, which made me strace the index build process. Which lead me to notice this: ... openat(AT_FDCWD, "base/16462/17747_fsm", O_RD

Re: Why is citext/regress failing on hamerkop?

Thomas Munro writes: > For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so > here's hoping for 100% green on master by Tuesday or so. Meanwhile, back at the ranch, it doesn't seem that changed anything: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2024-05-1

Re: GUC names in messages

Daniel Gustafsson writes: > On 16 May 2024, at 13:35, Peter Eisentraut wrote: >> - errmsg("WAL generated with full_page_writes=off was replayed " >> + errmsg("WAL generated with \"full_page_writes=off\" was replayed " > I'm not a fan of this syntax, but I at the same time can't offer a better i

Re: commitfest.postgresql.org is no longer fit for purpose

On 5/16/24 15:47, Tom Lane wrote: Daniel Gustafsson writes: On 16 May 2024, at 20:30, Robert Haas wrote: The original intent of CommitFests, and of commitfest.postgresql.org by extension, was to provide a place where patches could be registered to indicate that they needed to be reviewed, thus

Re: query_id, pg_stat_activity, extended query protocol

> I'm unsure if it needs to call ExecutorStart in the bind code. But if we > don't change the current logic, would it make more sense to move > pgstat_report_query_id to the ExecutorRun routine? I initially thought about that, but for utility statements (CTAS, etc.) being executed with extended q

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 2:30 PM Robert Haas wrote: > > Hi, > > The original intent of CommitFests, and of commitfest.postgresql.org > by extension, was to provide a place where patches could be registered > to indicate that they needed to be reviewed, thus enabling patch > authors and patch review

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 10:46 PM Melanie Plageman wrote: > On Thu, May 16, 2024 at 2:30 PM Robert Haas wrote: > > > > Hi, > > > > The original intent of CommitFests, and of commitfest.postgresql.org > > by extension, was to provide a place where patches could be registered > > to indicate that t

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 12:14 PM David G. Johnston wrote: > Those likely never get out of the new WIP slot discussed above. Your patch > tracker basically. And there should be less angst in moving something in the > bimonthly into WIP rather than dropping it outright. There is discussion to

Re: commitfest.postgresql.org is no longer fit for purpose

Melanie Plageman writes: > I was reflecting on why a general purpose patch tracker sounded > appealing to me, and I realized that, at least at this time of year, I > have a few patches that really count as "waiting on author" that I > know I need to do additional work on before they need more revi

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 1:46 PM Melanie Plageman wrote: > I should probably simply > withdraw and re-register them. My justification was that I'll lose > them if I don't keep them in the commitfest app. But, I could just, > you know, save them somewhere myself instead of polluting the > commitfest

Lowering the minimum value for maintenance_work_mem

Hi, In the subthread at [1] I needed to trigger multiple rounds of index vacuuming within one vacuum. It turns out that with the new dead tuple implementation, that got actually somewhat expensive. Particularly if all tuples on all pages get deleted, the representation is just "too dense". Normal

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote: > Maybe we should just make it a policy that *nothing* gets moved forward > from commitfest-to-commitfest and therefore the author needs to care > enough to register for the next one? I think that's going to severely disadvantage anyone who doesn'

Re: commitfest.postgresql.org is no longer fit for purpose

Hi, On 5/16/24 4:31 PM, Joe Conway wrote: Yeah.  I think that Robert put his finger on a big part of the problem, which is that punting a patch to the next CF is a lot easier than rejecting it, particularly for less-senior CFMs who may not feel they have the authority to say no (or at least doub

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 16 May 2024 at 18:57, Robert Haas wrote: > Ugh, it's so hard to communicate clearly about this stuff. I didn't > really have any thought that we'd ever try to handle something as > complicated as compression using ParameterSet. Okay, then it's definitely very hard to communicate clearly a

Re: commitfest.postgresql.org is no longer fit for purpose

Jacob Champion writes: > ... Similar to how people currently use the > Reviewer field as a personal TODO list... it might be nice to > officially separate the ideas a bit. Oh, that's an independent pet peeve of mine. Usually, if I'm looking over the CF list for a patch to review, I skip over one

Re: commitfest.postgresql.org is no longer fit for purpose

On 5/16/24 16:57, Jacob Champion wrote: On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote: Maybe we should just make it a policy that *nothing* gets moved forward from commitfest-to-commitfest and therefore the author needs to care enough to register for the next one? I think that's going to s

Re: Why is citext/regress failing on hamerkop?

On 2024-05-16 Th 16:18, Tom Lane wrote: Thomas Munro writes: For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so here's hoping for 100% green on master by Tuesday or so. Meanwhile, back at the ranch, it doesn't seem that changed anything: https://buildfarm.postgresql.org/cgi

Re: commitfest.postgresql.org is no longer fit for purpose

Jacob Champion writes: > On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote: >> Maybe we should just make it a policy that *nothing* gets moved forward >> from commitfest-to-commitfest and therefore the author needs to care >> enough to register for the next one? > I think that's going to severely

Re: commitfest.postgresql.org is no longer fit for purpose

On 5/16/24 16:48, Magnus Hagander wrote: On Thu, May 16, 2024 at 10:46 PM Melanie Plageman I was reflecting on why a general purpose patch tracker sounded appealing to me, and I realized that, at least at this time of year, I have a few patches that really count as "waiting on author

Re: Why is citext/regress failing on hamerkop?

Andrew Dunstan writes: > On 2024-05-16 Th 16:18, Tom Lane wrote: >> Andrew: maybe the buildfarm server could be made to flag >> animals building exceedingly old commits? This is the second >> problem of this sort that I've noticed this month, and you >> really have to look closely to realize it's

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 1:46 PM Melanie Plageman wrote: > > I should probably simply > withdraw and re-register them. My justification was that I'll lose > them if I don't keep them in the commitfest app. But, I could just, > you know, save them somewhere myself instead of polluting the > commitf

optimizing pg_upgrade's once-in-each-database steps

A number of pg_upgrade steps require connecting to each database and running a query. When there are many databases, these steps are particularly time-consuming, especially since this is done sequentially in a single process. At a quick glance, I see the following such steps: * create_lo

Re: TerminateOtherDBBackends code comments inconsistency.

On Tue, Apr 30, 2024 at 09:10:52AM +0530, Amit Kapila wrote: > On Tue, Apr 30, 2024 at 2:58 AM Noah Misch wrote: > > On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote: > > > 3a9b18b309 didn't change the docs of pg_terminate_backend and whatever > > > is mentioned w.r.t permissions in the

Re: commitfest.postgresql.org is no longer fit for purpose

On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote: > Maybe the word "care" was a poor choice, but forcing authors to think > about and decide if they have the "time to shepherd a patch" for the > *next CF* is exactly the point. If they don't, why clutter the CF with it. Because the community regul

Re: Why is citext/regress failing on hamerkop?

On 2024-05-16 Th 17:15, Tom Lane wrote: Andrew Dunstan writes: On 2024-05-16 Th 16:18, Tom Lane wrote: Andrew: maybe the buildfarm server could be made to flag animals building exceedingly old commits? This is the second problem of this sort that I've noticed this month, and you really have

Re: Minor cleanups in the SSL tests

> On 16 May 2024, at 11:43, Peter Eisentraut wrote: > You might want to run your patch through pgperltidy. The result doesn't look > bad, but a bit different than what you had crafted. Ugh, I thought I had but clearly had forgotten. Fixed now. > append_conf() opens and closes the file for eac

  1   2   >