On 17/05/2024 08:05, Peter Eisentraut wrote:
On 17.05.24 04:26, Robert Haas wrote:
I do*emphatically* think we need a parking lot.
People seem to like this idea; I'm not quite sure I follow it. If you
just want the automated patch testing, you can do that on your own by
setting up github/cir
On Thu, 16 May 2024 at 07:20, Peter Geoghegan wrote:
>
> On Tue, May 14, 2024 at 6:58 AM David Rowley wrote:
> > On Fri, 3 May 2024 at 16:03, David Rowley wrote:
> > > I'm trying to figure out why BufFileSize() Asserts that file->fileset
> > > isn't NULL, per 1a990b207.
> >
> > I was hoping to g
On Fri, May 17, 2024 at 12:25 AM Maciek Sakrejda
wrote:
> 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.
On 17/05/2024 05:26, Robert Haas wrote:
For bonus points, suppose we make it so that when you click the link,
it takes you to a box where you can type in a text comment that will
display in the app, explaining why your patch needs review: "Robert
says the wire protocol changes in this patch are w
> On 17 May 2024, at 07:57, Peter Eisentraut wrote:
>
> On 16.05.24 23:27, Daniel Gustafsson wrote:
>>> 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.
>>
On Thu, 16 May 2024 at 15:15, Peter Eisentraut wrote:
>
> I wonder if we can avoid making MERGE_ACTION a keyword.
>
Yeah, there was a lot of back and forth on this point on the original
thread, and I'm still not sure which approach is best.
> I think we could parse it initially as a function and
On Fri, 17 May 2024 at 06:58, Peter Eisentraut wrote:
> Yeah, some fine-tuning might be required. But I would be wary of
> over-designing too many new states at this point. I think the key idea
> is that there ought to be a state that communicates "needs attention
> from someone other than autho
On Wed, 15 May 2024 at 02:14, Erik Wienhold wrote:
>
> plpgsql fails to parse 1_000..1_000 as 1000..1000 in FOR loops:
>
> Fixed in the attached patch.
>
Nice catch! The patch looks good to me on a quick read-through.
I'll take a closer look next week, after the beta release, since it's
a v16+ b
> On 17 May 2024, at 09:32, Heikki Linnakangas wrote:
> On the mailing list, notes like that are both noisy and easily lost in the
> threads. But as a little free-form text box on the commitfest, it would be
> handy.
On a similar note, I have in the past suggested adding a free-form textfield
> On 17 May 2024, at 00:03, Peter Eisentraut wrote:
> I think, if we consider the core mission of the commitfest app, we need to be
> more protective of the Needs Review state.
IMHO this is a very very good summary of what we should focus on with this
work.
--
Daniel Gustafsson
On Fri, 17 May 2024 at 10:47, Daniel Gustafsson wrote:
> One way to ensure we capture detail could be if the system would send an
> automated email to the thread summarizing the entry when it's marked as
> "committed"?
This sounds great! Especially if Going back from an archived thread
to the co
On Fri, 17 May 2024 at 11:02, Jelte Fennema-Nio wrote:
>
> On Fri, 17 May 2024 at 10:47, Daniel Gustafsson wrote:
> > One way to ensure we capture detail could be if the system would send an
> > automated email to the thread summarizing the entry when it's marked as
> > "committed"?
>
> This soun
> On 16 May 2024, at 23:30, Robert Haas wrote:
>
I think we just need 10x CFMs. Let’s have a CFM for each CF section. I’d
happily take "Replication and Recovery” or “System Administration” for July.
“Miscellaneous” or “Performance” look monstrous.
I feel I can easily track ~20 threads (besi
I think there are actually a number of factors that make this much harder.
On Fri, May 17, 2024 at 2:33 PM Heikki Linnakangas wrote:
>
> On 17/05/2024 05:26, Robert Haas wrote:
> > For bonus points, suppose we make it so that when you click the link,
> > it takes you to a box where you can type i
On Thu, May 16, 2024 at 5:43 PM Richard Guo wrote:
> I have experimented with this approach, and here is the outcome. The
> patch fixes Geoff's query, but it's still somewhat messy as I'm not
> experienced enough in the parser code. And the patch has not yet
> implemented the nullingrel bit man
On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
> On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > However, parent's table extended statistics already covers all its
> > > > children.
> > >
> > > => That's the wrong explanation. It's not that "stats on the parent
>
On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov wrote:
> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
> wrote:
> > On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> > wrote:
> > > > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > > > wrote:
> > > > The only bt_target_page_check() ca
Hi, Alexander:
On Fri, 17 May 2024 at 14:05, Alexander Korotkov
wrote:
> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby
> wrote:
> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > > However, parent's table extended statistics already covers all its
> > > > > children
Hi, Alexander!
On Fri, 17 May 2024 at 14:11, Alexander Korotkov
wrote:
> On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov
> wrote:
> > On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
> > wrote:
> > > On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> > > wrote:
> > > > > On May 10, 2024, at
On 5/16/24 23:43, Peter Eisentraut wrote:
> On 16.05.24 23:06, Joe Conway wrote:
>> 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 ther
On Fri, May 17, 2024 at 1:05 AM Peter Eisentraut wrote:
> On 17.05.24 04:26, Robert Haas wrote:
> > I do*emphatically* think we need a parking lot.
>
> People seem to like this idea; I'm not quite sure I follow it. If you
> just want the automated patch testing, you can do that on your own by
>
Hi, Pavel!
On Fri, May 17, 2024 at 2:02 PM Pavel Borisov wrote:
> On Fri, 17 May 2024 at 14:05, Alexander Korotkov wrote:
>>
>> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby wrote:
>> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
>> > > > > However, parent's table extend
> On 17 May 2024, at 13:13, Robert Haas wrote:
> But if we are to guess what those reasons might be, Tom has already
> admitted he does that for CI, and I do the same, so probably other
> people also do it. I also suspect that some people are essentially
> using the CF app as a personal todo list
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
> Yeah, I 100% agree with this. If a patch bitrots and no one cares enough
> to rebase it once in a while, then sure - it's probably fine to mark it
> RwF. But forcing all contributors to do a dance every 2 months just to
> have a chance someone
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 the most
robust and sustainable solution.
(The remaining three patches from the v6 set
On 2024-May-17, Michael Paquier wrote:
> On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote:
> > I propose my original v1 patch for correcting the --help output of
> > 'postgres' too. I agree with the above comments that corresponding
> > changes in v4 became somewhat unwieldy.
>
On 5/16/24 22:26, Robert Haas wrote:
For example, imagine that the CommitFest is FORCIBLY empty
until a week before it starts. You can still register patches in the
system generally, but that just means they get CI runs, not that
they're scheduled to be reviewed. A week before the CommitFest,
eve
On Fri, May 17, 2024 at 1:18 AM David Steele wrote:
> However, I think allowing the user to optionally validate the input
> would be a good feature. Running pg_verifybackup as a separate step is
> going to be a more expensive then verifying/copying at the same time.
> Even with storage tricks to c
On Fri, 17 May 2024 at 13:39, Robert Haas wrote:
>
> On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
> wrote:
> > Yeah, I 100% agree with this. If a patch bitrots and no one cares enough
> > to rebase it once in a while, then sure - it's probably fine to mark it
> > RwF. But forcing all contributors
On Fri, 17 May 2024 at 14:19, Joe Conway wrote:
>
> On 5/16/24 22:26, Robert Haas wrote:
> > For example, imagine that the CommitFest is FORCIBLY empty
> > until a week before it starts. You can still register patches in the
> > system generally, but that just means they get CI runs, not that
> >
> On 16 May 2024, at 19:47, Tom Lane wrote:
> Yeah, it's not worth working harder than this. I do see one typo
> in your comment: s/supported then/supported when/. LGTM otherwise.
Thanks for review, I've pushed this (with the fix from above) to 14 through 12.
--
Daniel Gustafsson
On 5/17/24 08:31, Jelte Fennema-Nio wrote:
On Fri, 17 May 2024 at 14:19, Joe Conway wrote:
On 5/16/24 22:26, Robert Haas wrote:
> For example, imagine that the CommitFest is FORCIBLY empty
> until a week before it starts. You can still register patches in the
> system generally, but that just
On 17.05.24 13:36, Daniel Gustafsson wrote:
On 17 May 2024, at 13:13, Robert Haas wrote:
But if we are to guess what those reasons might be, Tom has already
admitted he does that for CI, and I do the same, so probably other
people also do it. I also suspect that some people are essentially
us
> On 17 May 2024, at 16:39, Robert Haas wrote:
>
> I think Andrey Borodin's nearby suggestion of having a separate CfM
> for each section of the CommitFest does a good job revealing just how
> bad the current situation is. I agree with him: that would actually
> work. Asking somebody, for a on
On Friday, May 17, 2024, Joe Conway wrote:
>
> I wrote:
>
>> Namely, the week before commitfest I don't actually know if I will have
>> the time during that month, but I will make sure my patch is in the
>> commitfest just in case I get a few clear days to work on it. Because if it
>> isn't there
Hello,
I decided to compare v17 vs v16 performance (as I did the last year [1])
and discovered that v17 loses to v16 in the pg_tpcds (s64da_tpcds)
benchmark, query15 (and several others, but I focused on this one):
Best pg-src-master--.* worse than pg-src-16--.* by 52.2 percents (229.84 >
151.03
On 17.05.24 09:32, Heikki Linnakangas wrote:
Dunno about having to click a link or sparkly gold borders, but +1 on
having a free-form text box for notes like that. Things like "cfbot says
this has bitrotted" or "Will review this after other patch this depends
on". On the mailing list, notes lik
On Fri, May 17, 2024 at 8:31 AM Jelte Fennema-Nio wrote:
> Such a proposal would basically mean that no-one that cares about
> their patches getting reviews can go on holiday and leave work behind
> during the week before a commit fest. That seems quite undesirable to
> me.
Well, then we make it
On Fri, May 17, 2024 at 9:02 AM Peter Eisentraut wrote:
> We already have the annotations feature, which is kind of this.
I didn't realize we had that feature. When was it added, and how is it
supposed to be used?
--
Robert Haas
EDB: http://www.enterprisedb.com
On 17.05.24 14:42, Joe Conway wrote:
Namely, the week before commitfest I don't actually know if I will
have the time during that month, but I will make sure my patch is in
the commitfest just in case I get a few clear days to work on it.
Because if it isn't there, I can't take advantage of tho
On 5/17/24 14:51, Andrey M. Borodin wrote:
>
>
>> On 17 May 2024, at 16:39, Robert Haas wrote:
>>
>> I think Andrey Borodin's nearby suggestion of having a separate CfM
>> for each section of the CommitFest does a good job revealing just how
>> bad the current situation is. I agree with him:
> On 17 May 2024, at 15:05, Robert Haas wrote:
>
> On Fri, May 17, 2024 at 9:02 AM Peter Eisentraut wrote:
>> We already have the annotations feature, which is kind of this.
>
> I didn't realize we had that feature. When was it added, and how is it
> supposed to be used?
A while back.
commit
hi.
https://wiki.postgresql.org/wiki/Todo
Dates and Times[edit]
Allow infinite intervals just like infinite timestamps
https://www.postgresql.org/message-id/4eb095c8.1050...@agliodbs.com
this done at
https://git.postgresql.org/cgit/postgresql.git/commit/?id=519fc1bd9e9d7b408903e44f55f83f6db30742b
On Thu, May 16, 2024 at 1:39 PM Jacob Burroughs
wrote:
> As currently implemented [1], the client sends the server the list of
> all compression algorithms it is willing to accept, and the server can
> use one of them. If the server knows what `_pq_.compression` means
> but doesn't actually suppo
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
>
> It will be improved until the final release. The item count is 188,
> which is simil
Re: Robert Haas
> Based on these comments and the one from David Johnston, I think there
> is a consensus that we do not want this patch, so I'm marking it as
> Rejected in the CommitFest application. If I've misunderstood the
> situation, then please feel free to change the status accordingly.
Hi
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
About the changes in collations:
Create a "builtin" collation provider similar to libc's C locale
(Jeff Davis
Re: Robert Haas
> IMHO, the big problem here is that different people want different
> corner-case behaviors and it's not clear what to do about that. I
> don't think there's a single vote for "don't do this at all". So if
> there is a desire to take this work forward, the goal probably ought
> to
On Fri, May 17, 2024 at 9:24 AM Christoph Berg wrote:
> Tom> The stated complaint was "it's too hard to build UPDATE commands",
> Tom> which I can sympathize with.
>
> ... which this would perfectly address - it's building the commands.
>
> The editor will have a bit more clutter (the UPDATE SET W
On 5/17/24 09:08, Peter Eisentraut wrote:
On 17.05.24 14:42, Joe Conway wrote:
Namely, the week before commitfest I don't actually know if I will
have the time during that month, but I will make sure my patch is in
the commitfest just in case I get a few clear days to work on it.
Because if it
On Fri, May 17, 2024 at 9:42 AM Christoph Berg wrote:
> Thanks for summarizing the thread.
>
> Things mentioned in the thread:
>
> 1) rendering of SQL NULLs - include or omit the column
>
> 2) rendering of JSON values - both "quoted string" and "inline as
>JSON" make sense
>
> 3) not quoting n
On Fri, May 17, 2024 at 9:54 AM Joe Conway wrote:
> I agree with you. Before commitfests were a thing, we had no structure
> at all as I recall. The dates for the dev cycle were more fluid as I
> recall, and we had no CF app to track things. Maybe retaining the
> structure but going back to the co
pá 17. 5. 2024 v 16:04 odesílatel Robert Haas
napsal:
> On Fri, May 17, 2024 at 9:42 AM Christoph Berg wrote:
> > Thanks for summarizing the thread.
> >
> > Things mentioned in the thread:
> >
> > 1) rendering of SQL NULLs - include or omit the column
> >
> > 2) rendering of JSON values - both "
On Fri, May 17, 2024 at 9:09 AM Peter Eisentraut wrote:
> How would the development process look like if we
> just had one commitfest per dev cycle that runs from July 1st to March 31st?
Exactly the same?
--
Peter Geoghegan
Robert Haas writes:
> On Fri, May 17, 2024 at 9:54 AM Joe Conway wrote:
>> I agree with you. Before commitfests were a thing, we had no structure
>> at all as I recall. The dates for the dev cycle were more fluid as I
>> recall, and we had no CF app to track things. Maybe retaining the
>> structu
On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
> To my mind, the point of the time-boxed commitfests is to provide
> a structure wherein people will (hopefully) pay some actual attention
> to other peoples' patches. Conversely, the fact that we don't have
> one running all the time gives commit
On Fri, 2024-05-17 at 10:12 +0900, Michael Paquier wrote:
> That's something I've done four weeks ago in the hash replay code
> path, and having the image with XLR_CHECK_CONSISTENCY even if
> REGBUF_NO_CHANGE was necessary because replay was setting up a LSN on
> a REGBUF_NO_CHANGE page it should n
Robert Haas writes:
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
>> If we go back to the old its-development-mode-all-the-time approach,
>> what is likely to happen is that the commit rate for not-your-own-
>> patches goes to zero, because it's always possible to rationalize
>> your own stu
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From ded5e61ff631c2d02835fdba941068dcd86741ce Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 18 Apr 2024 15:15:19 -0500
Subject: [PATCH v5 1/2] Remove is_index parameter from
binary_upgrade_set_pg_class_oids().
--
On Fri, May 17, 2024 at 10:56 AM Jeff Davis wrote:
> I'm still not entirely clear on why hash indexes can't just follow the
> rules and exclusive lock the buffer and dirty it. Presumably
> performance would suffer, but I asked that question previously and
> didn't get an answer:
>
> https://www.po
Peter Eisentraut writes:
> On 16.05.24 16:45, Tom Lane wrote:
>> Yeah, that was bothering me too, but I went for the minimum delta.
>> I did think that a couple of integer macros would be a better idea,
>> so +1 for what you did here.
> I committed this, and Michael took care of WaitEventExtensio
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
>
> On 5/16/24 23:43, Peter Eisentraut wrote:
> > On 16.05.24 23:06, Joe Conway wrote:
> >> 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 *nothin
On Fri, May 17, 2024 at 7:40 AM Robert Haas wrote:
>
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
> > To my mind, the point of the time-boxed commitfests is to provide
> > a structure wherein people will (hopefully) pay some actual attention
> > to other peoples' patches. Conversely, the f
Melanie Plageman writes:
> So, anyway, I'd argue that we need a parking lot for patches which we
> all agree are important and have a path forward but need someone to do
> the last 20-80% of the work. To avoid this being a dumping ground,
> patches should _only_ be allowed in the parking lot if th
On Fri, May 17, 2024 at 11:05 AM Tom Lane wrote:
> > We already have gone back to that model. We just haven't admitted it
> > yet. And we're never going to get out of it until we find a way to get
> > the contents of the CommitFest application down to a more reasonable
> > size and level of comple
On Fri, May 17, 2024 at 11:57 AM Tom Lane wrote:
> Melanie Plageman writes:
> > So, anyway, I'd argue that we need a parking lot for patches which we
> > all agree are important and have a path forward but need someone to do
> > the last 20-80% of the work. To avoid this being a dumping ground,
>
On Fri, May 17, 2024 at 9:13 AM Pavel Stehule wrote:
> after migration on PostgreSQL 16 I seen 3x times (about every week) broken
> tables on replica nodes. The query fails with error
>
> ERROR: could not access status of transaction 1442871302
> DETAIL: Could not open file "pg_xact/0560": No s
On 5/17/24 11:58, Robert Haas wrote:
I realize that many people here are (rightly!) concerned with
burdening patch authors with more steps that they have to follow. But
the current system is serving new patch authors very poorly. If they
get attention, it's much more likely to be because somebody
On Fri, 17 May 2024 at 17:59, Robert Haas wrote:
> If they
> get attention, it's much more likely to be because somebody saw their
> email and wrote back than it is to be because somebody went through
> the CommitFest and found their entry and was like "oh, I should review
> this".
I think this i
Hi, forgive the top-post but I have not seen any response to this post?
Thanks,
Paul
> -Original Message-
> From: Amonson, Paul D
> Sent: Wednesday, May 1, 2024 8:56 AM
> To: pgsql-hackers@lists.postgresql.org
> Cc: Nathan Bossart ; Shankaran, Akash
>
> Subject: Proposal for Updating CRC
"David G. Johnston" writes:
> On Friday, May 17, 2024, Joe Conway wrote:
>> A solution to both of these issues (yours and mine) would be to allow
>> things to be added *during* the CF month. What is the point of having a
>> "freeze" before every CF anyway? Especially if they start out clean. If
>
TAKATSUKA Haruka writes:
> I'm a hamerkop maintainer.
> Sorry I have missed the scm error for so long.
> Today I switched scmrepo from git.postgresql.org/git/postgresql.git
> to github.com/postgres/postgres.git and successfully modernized
> the build target code.
Thanks very much! I see hamerk
(moving to a new thread)
On Thu, May 16, 2024 at 09:16:46PM -0500, Nathan Bossart wrote:
> On Thu, May 16, 2024 at 04:37:10PM +, Imseih (AWS), Sami wrote:
>> Also, Not sure if I am mistaken here, but the "+ 5" in the existing docs
>> seems wrong.
>>
>> If it refers to NUM_AUXILIARY_PROCS def
On Fri, May 17, 2024 at 9:12 AM jian he wrote:
> https://wiki.postgresql.org/wiki/Todo
> Dates and Times[edit]
> Allow infinite intervals just like infinite timestamps
> https://www.postgresql.org/message-id/4eb095c8.1050...@agliodbs.com
>
> this done at
> https://git.postgresql.org/cgit/postgresq
Nathan Bossart writes:
> [ many, many problems in documented formulas ]
> At a bare minimum, we should probably fix the obvious problems, but I
> wonder if we could simplify this section a bit, too.
Yup. "The definition of insanity is doing the same thing over and
over and expecting different r
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
> It does seem to me a part of the solution needs to be helping to get
> those patches reviewed. I don't know how to do that, but perhaps there's
> a way to encourage people to review more stuff, or review stuff from a
> wider range of contribut
pá 17. 5. 2024 v 18:02 odesílatel Peter Geoghegan napsal:
> On Fri, May 17, 2024 at 9:13 AM Pavel Stehule
> wrote:
> > after migration on PostgreSQL 16 I seen 3x times (about every week)
> broken tables on replica nodes. The query fails with error
> >
> > ERROR: could not access status of trans
On Fri, May 17, 2024 at 1:18 PM Pavel Stehule wrote:
> pá 17. 5. 2024 v 18:02 odesílatel Peter Geoghegan napsal:
>> You've shown an inconsistency between the primary and standby with
>> respect to the heap tuple infomask bits related to freezing. It looks
>> like a FREEZE WAL record from the prim
On Fri, May 17, 2024 at 3:15 AM Robert Haas wrote:
>
> OK, so you made it so that compressed data is fully self-identifying.
> Hence, there's no need to worry if something gets changed: the
> receiver, if properly implemented, can't help but notice. The only
> downside that I can see to this desig
> On May 17, 2024, at 3:11 AM, Alexander Korotkov wrote:
>
> On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov
> wrote:
>> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
>> wrote:
>>> On Sat, May 11, 2024 at 4:13 AM Mark Dilger
>>> wrote:
> On May 10, 2024, at 12:05 PM, Alexander
On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
> Thoughts?
The patch as proposed seems fine. Marking RfC.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, May 17, 2024 at 01:09:55PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> [ many, many problems in documented formulas ]
>
>> At a bare minimum, we should probably fix the obvious problems, but I
>> wonder if we could simplify this section a bit, too.
>
> Yup. "The definition of ins
On Sat, 11 May 2024 at 15:36, AJ ONeal wrote:
> Having postgres TLS/SNI/ALPN routable by default will just be more intuitive
> (it's what I assumed would have been the default anyway), and help increase
> adoption in cloud, enterprise, and other settings.
Routing is primarily a feature for "cl
On Thu, May 16, 2024 at 4:57 AM Aleksander Alekseev
wrote:
> I propose my original v1 patch for correcting the --help output of
> 'postgres' too. I agree with the above comments that corresponding
> changes in v4 became somewhat unwieldy.
So, who is it exactly that will be confused by the status
Robert Haas writes:
> If the reason that somebody is upset is because it's not technically
> true to say that you *must* do one of those things, we could fix that
> with "You must" -> "You can" or with "You must specify" -> "Specify".
> The patch you propose is also not terrible or anything, but i
>>> If the exact values
>>> are important, maybe we could introduce more GUCs like
>>> shared_memory_size_in_huge_pages that can be consulted (instead of
>>> requiring users to break out their calculators).
>>
>> I don't especially like shared_memory_size_in_huge_pages, and I don't
>> want to intro
Hi, Mark!
> The documentation in
> https://www.postgresql.org/docs/devel/amcheck.html#AMCHECK-FUNCTIONS is
> ambiguous:
>
> "bt_index_check does not verify invariants that span child/parent
> relationships, but will verify the presence of all heap tuples as index
> tuples within the index when hea
On Fri, Mar 29, 2024 at 1:09 PM Jeff Davis wrote:
> I am fine with this.
>
> You've moved the discussion forward in two ways:
>
> 1. Changes to pg_stat_statements to actually use the API; and
> 2. The hook is called at multiple points.
>
> Those at least partially address the concerns raised b
> On May 17, 2024, at 11:51 AM, Pavel Borisov wrote:
>
> Amcheck with checkunique option does check uniqueness violation between
> pages. But it doesn't warranty detection of cross page uniqueness violations
> in extremely rare cases when the first equal index entry on the next page
> corre
On Fri, May 17, 2024 at 12:48:37PM -0500, Nathan Bossart wrote:
> On Fri, May 17, 2024 at 01:09:55PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> At a bare minimum, we should probably fix the obvious problems, but I
>>> wonder if we could simplify this section a bit, too.
>>
>> Yup. "The
On Fri, May 17, 2024 at 1:26 PM Jacob Burroughs
wrote:
> I was leaving the details around triggering that for this conversation
> and in that patch just designing the messages in a way that would
> allow adding the reconfiguration/restarting to be easily added in a
> backwards-compatible way in a
On Fri, May 17, 2024 at 06:30:08PM +, Imseih (AWS), Sami wrote:
>> The advantage of the GUC is that its value could be seen before trying to
>> actually start the server.
>
> Only if they have a sample in postgresql.conf file, right?
> A GUC like shared_memory_size_in_huge_pages will not be.
Hi,
On 2024-05-17 18:30:08 +, Imseih (AWS), Sami wrote:
> > The advantage of the GUC is that its value could be seen before trying to
> > actually start the server.
>
> Only if they have a sample in postgresql.conf file, right?
> A GUC like shared_memory_size_in_huge_pages will not be.
You ca
> postgres -D pgdev-dev -c shared_buffers=16MB -C
> shared_memory_size_in_huge_pages
> 13
> postgres -D pgdev-dev -c shared_buffers=16MB -c huge_page_size=1GB -C
> shared_memory_size_in_huge_pages
> 1
> Which is very useful to be able to actually configure that number of huge
> pages. I don't t
Hi,
I've been looking at GiST to see if there could be a good way to do
parallel builds - and there might be, if the opclass supports sorted
builds, because then we could parallelize the sort.
But then I noticed we support this mode only for point_ops, because
that's the only opclass with sortsup
> On May 17, 2024, at 12:10 PM, Mark Dilger
> wrote:
>
>> Amcheck with checkunique option does check uniqueness violation between
>> pages. But it doesn't warranty detection of cross page uniqueness violations
>> in extremely rare cases when the first equal index entry on the next page
>>
Hi, Mark!
On Fri, 17 May 2024 at 23:10, Mark Dilger
wrote:
>
>
> > On May 17, 2024, at 11:51 AM, Pavel Borisov
> wrote:
> >
> > Amcheck with checkunique option does check uniqueness violation between
> pages. But it doesn't warranty detection of cross page uniqueness
> violations in extremely r
Hi,
On 2024-05-17 15:12:31 +0200, Pavel Stehule wrote:
> after migration on PostgreSQL 16 I seen 3x times (about every week) broken
> tables on replica nodes. The query fails with error
Migrating from what version?
You're saying that the data is correctly accessible on primaries, but broken
on
On Fri, 2024-05-17 at 13:12 -0400, Greg Sabino Mullane wrote:
> > Long time ago there was a "rule" that people submitting patches are expected
> > to do reviews. Perhaps we should be more strict this.
>
> Big -1. How would we even be more strict about this? Public shaming?
> Withholding a commit?
On Thu, Feb 29, 2024 at 2:21 AM Michael Paquier wrote:
> It's been brought to me that an extension may finish by breaking the
> assumptions ProcessUtility() relies on when calling
> standard_ProcessUtility(), causing breakages when passing down data to
> cascading utility hooks.
>
> Isn't the stat
1 - 100 of 141 matches
Mail list logo
