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

On Mon, May 20, 2024 at 1:09 PM Tom Lane wrote: > (The cfbot tends to discourage this, since as soon as one of the > patches is committed it no longer knows how to apply the rest. > Can we improve on that tooling somehow?) Cfbot currently applies patches with (GNU) patch --no-backup-if-mismatch

Re: Lowering the minimum value for maintenance_work_mem

On Fri, May 17, 2024 at 5:55 AM Andres Freund wrote: > > 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

Injection points: preloading and runtime arguments

Hi all, I have a couple of extra toys for injection points in my bucket that I'd like to propose for integration in v18, based on some feedback I have received: 1) Preload an injection point into the backend-level cache without running it. This has come up because an injection point run for the

Re: Underscore in positional parameters?

Erik Wienhold writes: > On 2024-05-20 03:26 +0200, jian he wrote: >> /* Check parameter number is in range */ >> if (paramno <= 0 || paramno > MaxAllocSize / sizeof(Oid)) >> ereport(ERROR, ... > Yes, it makes sense to show the upper bound. How about a hint such as > "Valid parameters range

Re: Underscore in positional parameters?

On 2024-05-20 03:26 +0200, jian he wrote: > On Sun, May 19, 2024 at 10:43 PM Erik Wienhold wrote: > > > > On 2024-05-19 07:00 +0200, Alexander Lakhin wrote: > > > I encountered anomalies that you address with this patch too. > > > And I can confirm that it fixes most cases, but there is another

Re: Underscore in positional parameters?

On Sun, May 19, 2024 at 10:43 PM Erik Wienhold wrote: > > On 2024-05-19 07:00 +0200, Alexander Lakhin wrote: > > I encountered anomalies that you address with this patch too. > > And I can confirm that it fixes most cases, but there is another one: > > SELECT $3 \bind 'foo' \g > > ERROR:

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

Bruce Momjian writes: > On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote: >> * Another reason for things sitting a long time is that they're too >> big to review without an unreasonable amount of effort. We should >> encourage authors to break large patches into smaller stepwise >>

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

On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote: > * Another reason for things sitting a long time is that they're too > big to review without an unreasonable amount of effort. We should > encourage authors to break large patches into smaller stepwise > refinements. It may seem like

Re: First draft of PG 17 release notes

On Sun, May 19, 2024 at 03:53:38PM +1200, David Rowley wrote: > On Sun, 19 May 2024 at 02:40, Bruce Momjian wrote: > > > > On Thu, May 16, 2024 at 03:35:17PM +1200, David Rowley wrote: > > > "Additionally, vacuum no longer silently imposes a 1GB tuple reference > > > limit even when

Re: in parentesis is not usual on DOCs

On Thu, May 16, 2024 at 12:14 PM jian he wrote: > > On Wed, May 15, 2024 at 8:34 PM Daniel Gustafsson wrote: > > > > > On 15 May 2024, at 14:04, Marcos Pegoraro wrote: > > > > > Why (context_item), (path_expression) and (json_path_name) are inside a > > > parentheses ? This is not usual when

Re: PostgreSQL 17 Beta 1 release announcement draft

On Mon, 20 May 2024 at 09:35, Jonathan S. Katz wrote: > Thanks for all the feedback to date. Please see the next revision. > Again, please provide feedback no later than 2024-05-22 18:00 UTC. Thanks for the updates. > [`COPY`](https://www.postgresql.org/docs/17/sql-copy.html) is used to >

Re: GUC names in messages

On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut wrote: > > On 17.05.24 05:31, Peter Smith 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

Re: PostgreSQL 17 Beta 1 release announcement draft

Op 5/19/24 om 23:34 schreef Jonathan S. Katz: On 5/15/24 9:45 PM, Jonathan S. Katz wrote: Hi, Attached is a copy of the PostgreSQL 17 Beta 1 release announcement 'This release introduces adds an interface' should be: 'This release adds an interface' (or 'introduces'; just not both...)

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/15/24 9:45 PM, Jonathan S. Katz wrote: Hi, Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft. This contains a user-facing summary of some of the features that will be available in the Beta, as well as a call to test. I've made an effort to group them logically

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/16/24 8:05 AM, 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. "You can find information

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/16/24 6:41 AM, Jelte Fennema-Nio wrote: 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.

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/16/24 1:15 AM, Bertrand Drouvot wrote: Hi, On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz wrote: Hi, Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft. Thanks for working on it! I've one comment: PostgreSQL 17 also introduces a new view,

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/16/24 1:10 AM, Thom Brown wrote: On Thu, May 16, 2024, 02:45 Jonathan S. Katz > wrote: Hi, Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft. This contains a user-facing summary of some of the features that will be

Re: PostgreSQL 17 Beta 1 release announcement draft

On 5/15/24 10:42 PM, David Rowley wrote: Thanks for writing that up. It's always exciting to see this each year. On Thu, 16 May 2024 at 13:45, Jonathan S. Katz wrote: * Please indicate if you believe there's a notable omission, or if we should omit any of these callouts I'd say the

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

> On 19 May 2024, at 22:21, Peter Eisentraut wrote: > Whoever commits these should be sure to coordinate this. Thanks for the reminder. I have this patchset, the OCSP stapling patchset and the multiple-cert one on my radar for when I do the 1.1.0 removal work in the July CF. Will do another

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

On 19.05.24 20:07, David Benjamin wrote: On Sun, May 19, 2024 at 12:21 PM Tom Lane > wrote: Per the cfbot [1], this patch needs a rebase over the ALPN-related commits.  It still isn't likely to get human attention before the July commitfest, but you can

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

Dmitry Dolgov <9erthali...@gmail.com> writes: > There are lots of good takes on this in the thread. It also makes clear what's > at stake -- as Melanie pointed out with the patch about EXPLAIN for parallel > bitmap heap scan, we're loosing potential contributors for no reasons. But I'm > a bit

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

On Sun, May 19, 2024 at 12:21 PM Tom Lane wrote: > Per the cfbot [1], this patch needs a rebase over the ALPN-related > commits. It still isn't likely to get human attention before the > July commitfest, but you can save some time by making sure it's > in a reviewable state before that. >

Re: State of pg_createsubscriber

On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote: > I'm fairly disturbed about the readiness of pg_createsubscriber. > The 040_pg_createsubscriber.pl TAP test is moderately unstable > in the buildfarm [1], and there are various unaddressed complaints > at the end of the patch thread (pretty much

State of pg_createsubscriber

I'm fairly disturbed about the readiness of pg_createsubscriber. The 040_pg_createsubscriber.pl TAP test is moderately unstable in the buildfarm [1], and there are various unaddressed complaints at the end of the patch thread (pretty much everything below [2]). I guess this is good enough to start

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

Daniel Gustafsson writes: > On 19 Apr 2024, at 15:13, David Benjamin wrote: >> Circling back here, anything else needed from my end on this patch? > Patience mostly, v17 very recently entered feature freeze so a lof of the > developers are busy finding and fixing bugs to stabilize the >

Re: Underscore in positional parameters?

On 2024-05-19 07:00 +0200, Alexander Lakhin wrote: > I encountered anomalies that you address with this patch too. > And I can confirm that it fixes most cases, but there is another one: > SELECT $3 \bind 'foo' \g > ERROR:  invalid memory alloc request size 12 > > Maybe you would

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

On 5/19/24 05:37, Dmitry Dolgov wrote: * How to deal with review scalability bottleneck. An evergreen question. PostgreSQL is getting more popular and, as stated in diverse research whitepapers, the amount of contribution grows as a power law, where the number of reviewers grows at

postgresql 17 (testing) SLES 15.5 missing "repodata" ..

postgresql 17 (testing)  SLES 15.5  missing "repodata"  so i can´t add repo to OpenSUSE... Please add...  thank you.. url: https://download.postgresql.org/pub/repos/zypp/testing/17/suse/sles-15.5-x86_64/

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

> On Thu, May 16, 2024 at 02:30:03PM -0400, Robert Haas wrote: > > I wonder what ideas people have for improving this situation. I doubt > that there's any easy answer that just makes the problem go away -- > keeping large groups of people organized is a tremendously difficult > task under pretty

Re: Avoid orphaned objects dependencies, take 3

Hello Bertrand, 15.05.2024 11:31, Bertrand Drouvot wrote: On Wed, May 15, 2024 at 10:14:09AM +0900, Michael Paquier wrote: +if (object_description) +ereport(ERROR, errmsg("%s does not exist", object_description)); +else +ereport(ERROR,

Re: Multiple startup messages over the same connection

On Sat, 18 May 2024 at 23:10, Vladimir Churyukin wrote: > I guess the process of passing control from child processes to the parent > could be a bit tricky for that one, but doable? > Is there anything I'm missing that can be a no-go for this? One seriously difficult/possibly impossible thing