> On 18 May 2024, at 00:41, Tomas Vondra wrote:
>
> if the opclass supports sorted
> builds, because then we could parallelize the sort.
Hi Tomas!
Yup, I'd also be glad to see this feature. PostGIS folks are using their
geometry (sortsupport was developed for this) with object id (this disa
On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen wrote:
> This comment on ProcSleep() seems to have the values of dontWait
> backward (double negatives are tricky):
>
> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
> PROC_WAIT_STATUS_ERROR
> * if not (if dontWait = true, this is a d
On Fri, May 17, 2024 at 4:46 PM Thomas Munro wrote:
> The specific problem here is that LocalProcessControlFile() runs in
> every launched child for EXEC_BACKEND builds. Windows uses
> EXEC_BACKEND, and Windows' NTFS file system is one of the two file
> systems known to this list to have the conc
On Mon, Mar 18, 2024 at 10:41 PM Heikki Linnakangas wrote:
> Committed, with some final cosmetic cleanups. Thanks everyone!
Nitpicking from UBSan with EXEC_BACKEND on Linux (line numbers may be
a bit off, from a branch of mine):
../src/backend/postmaster/launch_backend.c:772:2: runtime error: nu
On Fri, May 17, 2024 at 11:40 AM Robert Haas wrote:
>
> To be clear, I am not arguing that it should be the receiver's choice.
> I'm arguing it should be the client's choice, which means the client
> decides what it sends and also tells the server what to send to it.
> I'm open to counter-argument
On Sat, May 18, 2024 at 11:30 AM Thomas Munro wrote:
> Andres happened to have TPC-DS handy, and reproduced that regression
> in q15. We tried some stuff and figured out that it requires
> parallel_leader_participation=on, ie that this looks like some kind of
> parallel fairness and/or timing pro
On Fri, May 17, 2024 at 03:53:58PM -0400, Robert Haas wrote:
> The usual pattern for using hooks like this is to call the next
> implementation, or the standard implementation, and pass down the
> arguments that you got. If you try to do that and mess it up, you're
> going to get a crash really, re
On Fri, May 17, 2024 at 01:41:29PM -0400, Robert Haas wrote:
> On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
>> Thoughts?
>
> The patch as proposed seems fine. Marking RfC.
Thanks. I'll look again at that once v18 opens up for business.
--
Michael
signature.asc
Description: PGP sign
On 2024-05-18 03:27 +0200, David G. Johnston wrote:
> > On 2024-05-16 17:47 +0200, David G. Johnston wrote:
> > > We have a glossary.
>
> If sticking with stand-alone composite type as a formal term we should
> document it in the glossary. It's unclear whether this will survive review
> though.
On 2024-05-17 02:06 +0200, Michael Paquier wrote:
> On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
> > On this specific patch, maybe reword "parameter too large" to "parameter
> > number too large".
>
> WFM here.
Done in v3.
I noticed this compiler warning with my previous pat
On Fri, May 17, 2024 at 4:57 PM Erik Wienhold wrote:
> On 2024-05-16 17:47 +0200, David G. Johnston wrote:
> > 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 th
On Fri, May 17, 2024 at 12:41 PM Tomas Vondra
wrote:
> 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 f
On 2024-05-16 17:47 +0200, David G. Johnston wrote:
> 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.
> >
> > Revi
On Fri, 17 May 2024 at 21:24, Robert Haas wrote:
> I think the
> fear that we're going to run into cases where such complex handshaking
> is necessary is a major reason why I'm afraid of Jelte's ideas about
> ParameterSet: it seems much more opinionated to me than he seems to
> think it is.
I thi
On Sat, May 18, 2024 at 8:09 AM Thomas Munro wrote:
> On Sat, May 18, 2024 at 1:00 AM Alexander Lakhin wrote:
> > 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 oth
On Fri, 17 May 2024 at 23:10, Jacob Champion
wrote:
> We're talking about a transport-level option, though -- I thought the
> proposal enabled compression before authentication completed? Or has
> that changed?
I think it would make sense to only compress messages after
authentication has complet
On Fri, 17 May 2024 at 23:40, Robert Haas wrote:
> To be clear, I am not arguing that it should be the receiver's choice.
> I'm arguing it should be the client's choice, which means the client
> decides what it sends and also tells the server what to send to it.
> I'm open to counter-arguments, bu
On 17.05.24 23:01, Robert Haas wrote:
On Fri, May 17, 2024 at 4:59 PM Tom Lane wrote:
As I mentioned upthread, I'm more worried about confusing error
reports than the machine time.
Well, Jelte fixed that.
I grant that there are people who are more affected, but still, I'd
just as soon not c
On 5/17/24 22:20, Robert Haas wrote:
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 tim
On Fri, May 17, 2024 at 4:53 PM Jacob Burroughs
wrote:
> I think I was more thinking that trying to let both parties control
> the parameter seemed like a recipe for confusion and sadness, and so
> the choice that felt most natural to me was to let the sender control
> it, but I'm definitely open
On Thu, May 16, 2024 at 08:37:43AM -0400, Robert Haas wrote:
> 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. I
On Fri, May 17, 2024 at 1:53 PM Jacob Burroughs
wrote:
> New proposal, predicated on the assumption that if you enable
> compression you are ok with the client picking whatever level they
> want. At least with the currently enabled algorithms I don't think
> any of them are so insane that they wo
Hi, Mark!
> > At the first glance it's not clear to me:
> > - why your test creates cross-page unique constraint violations?
>
> To see if they are detected.
>
> > - how do you know they are not detected?
>
> It appears that they are detected. At least, rerunning the test after
> adjusting the ex
Robert Haas writes:
> On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
>> I think it is a good rule. I don't think that it shouldn't lead to putting
>> people on the pillory or kicking their patches, but I imagine that a
>> committer
>> looking for somebody else's patch to work on could pref
On Fri, May 17, 2024 at 4:59 PM Tom Lane wrote:
> As I mentioned upthread, I'm more worried about confusing error
> reports than the machine time.
Well, Jelte fixed that.
> I grant that there are people who are more affected, but still, I'd
> just as soon not contort the build rules for a tempor
Robert Haas writes:
> If this is the consensus opinion, then
> https://commitfest.postgresql.org/48/4914/ should be marked Rejected.
> However, while I think the improvements that Tom was able to make here
> sound fantastic, I don't understand why that's an argument against
> Jelte's patches. Afte
On Thu, May 16, 2024 at 3:28 AM Robert Haas wrote:
>
> Well, I mean, I don't really know what the right answer is here, but
> right now I can say pg_dump --compress=gzip to compress the dump with
> gzip, or pg_dump --compress=gzip:9 to compress with gzip level 9. Now,
> say that instead of compres
pá 17. 5. 2024 v 22:05 odesílatel Pavel Stehule
napsal:
>
>
> pá 17. 5. 2024 v 21:50 odesílatel Andres Freund
> napsal:
>
>> 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 node
On Thu, 2024-05-09 at 00:03 -0400, 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
For this item:
Create a "builtin" collation provider similar to libc's C
local
On 5/17/24 21:59, Robert Haas wrote:
> On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
>> 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
On Fri, May 17, 2024 at 4:20 PM Jeff Davis wrote:
> Regarding this particular change: the checkpointing hook seems more
> like a table AM feature, so I agree with you that we should have a good
> idea how a real table AM might use this, rather than only
> pg_stat_statements.
I would even be OK wi
On Fri, 2024-05-17 at 14:56 -0400, Robert Haas wrote:
> (2) a detailed
> description of how a non-core table AM or index AM is expected to be
> able to make use of this. Bonus points if the person providing that
> rationale can say credibly that they've actually implemented this and
> it works grea
On Wed, Apr 17, 2024 at 11:11 PM Tom Lane wrote:
> I think we should hold off on this. I found a simpler way to address
> ecpg's problem than what I sketched upthread. I have a not-ready-to-
> show-yet patch that allows the vast majority of ecpg's grammar
> productions to use the default semanti
On Fri, May 17, 2024 at 4:10 PM Mark Dilger
wrote:
> The quick-and-dirty TAP test I wrote this morning is intended to introduce
> duplicates across page boundaries, not to test for ones that got there by
> normal database activity. In other words, the TAP test forcibly corrupts the
> index by
> On May 17, 2024, at 1:00 PM, Peter Geoghegan wrote:
>
> Many different parts of the B-Tree code will fight against allowing
> duplicates of the same value to span multiple leaf pages -- this is
> especially true for unique indexes.
The quick-and-dirty TAP test I wrote this morning is inten
On Sat, May 18, 2024 at 1:00 AM Alexander Lakhin wrote:
> 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--.* wor
> On May 17, 2024, at 12:42 PM, Pavel Borisov wrote:
>
> At the first glance it's not clear to me:
> - why your test creates cross-page unique constraint violations?
To see if they are detected.
> - how do you know they are not detected?
It appears that they are detected. At least, rerunn
pá 17. 5. 2024 v 21:50 odesílatel Andres Freund napsal:
> 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?
>
I think
On Fri, May 17, 2024 at 3:50 PM Andres Freund wrote:
> You're saying that the data is correctly accessible on primaries, but broken
> on standbys? Is there any difference in how the page looks like on the primary
> vs standby?
There clearly is. The relevant infomask bits are different. I didn't
e
On Fri, May 17, 2024 at 3:42 PM Mark Dilger
wrote:
> On further review, the test was not anticipating the error message "high key
> invariant violated for index". That wasn't seen in calls to
> bt_index_parent_check(), but appears as one of the errors from
> bt_index_check(). I am rerunning t
On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
> 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 eve
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
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?
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
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
> 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,
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
> 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,
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
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.
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 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 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, 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
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
>>> 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
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
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
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 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 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 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 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 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
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 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
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 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
(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
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
"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
>
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
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
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, 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 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 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
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 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
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
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 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
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().
--
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
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
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
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 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
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: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
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 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: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
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
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
> 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
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
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
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 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
1 - 100 of 141 matches
Mail list logo
