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 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: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
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 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
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 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 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 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, 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 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 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 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
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, 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
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 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:
> 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
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
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
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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 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
101 - 141 of 141 matches
Mail list logo
