On Wed, 10 Apr 2024 at 17:18, Tom Lane wrote:
>
> David Rowley writes:
> > I think a better fix is just to not apply the optimisation for
> > inheritance RTEs in add_base_clause_to_rel().
>
> Is it worth paying attention to whether the constraint is marked
> connoinherit? If that involves an
On Wed, Apr 10, 2024 at 11:00 AM Heikki Linnakangas wrote:
>
> On 10/04/2024 07:45, Michael Paquier wrote:
> > On Tue, Apr 09, 2024 at 09:16:53PM -0700, Jeff Davis wrote:
> >> On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote:
> >>> Wouldn't the best way forward be to revert
> >>>
On 10/04/2024 07:45, Michael Paquier wrote:
On Tue, Apr 09, 2024 at 09:16:53PM -0700, Jeff Davis wrote:
On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote:
Wouldn't the best way forward be to revert
5bec1d6bc5e3 and revisit the whole in v18?
Also consider commits b840508644 and
David Rowley writes:
> I think a better fix is just to not apply the optimisation for
> inheritance RTEs in add_base_clause_to_rel().
Is it worth paying attention to whether the constraint is marked
connoinherit? If that involves an extra syscache fetch, I'd tend to
agree that it's not worth
On Tue, 9 Apr 2024 at 21:55, Richard Guo wrote:
>
> In b262ad440e we introduced an optimization that drops IS NOT NULL quals
> on a NOT NULL column, and reduces IS NULL quals on a NOT NULL column to
> constant-FALSE. I happened to notice that this is not working correctly
> for traditional
Thomas Munro writes:
> On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
>> ... On my Mac laptop
>> (Apple clang version 15.0.0), the compile time for preproc.o went from
>> 6.7sec to 5.5sec.
> Having seen multi-minute compile times on FreeBSD (where clang is the
> system compiler) and Debian
On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
> ... On my Mac laptop
> (Apple clang version 15.0.0), the compile time for preproc.o went from
> 6.7sec to 5.5sec.
Having seen multi-minute compile times on FreeBSD (where clang is the
system compiler) and Debian (where I get packages from
On Tue, Apr 09, 2024 at 12:41:57PM +0900, Michael Paquier wrote:
> Applied that after a second check. And thanks to Bharath for the
> poke.
And now that the buildfarm is cooler, I've also applied the final
patch in the series as of 5105c9079681 to make the GIN module
concurrent-safe using
On Tue, Apr 09, 2024 at 09:16:53PM -0700, Jeff Davis wrote:
> On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote:
>> Wouldn't the best way forward be to revert
>> 5bec1d6bc5e3 and revisit the whole in v18?
>
> Also consider commits b840508644 and bcb14f4abc.
Indeed. These are also linked.
On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote:
> Wouldn't the best way forward be to revert
> 5bec1d6bc5e3 and revisit the whole in v18?
That's a reasonable conclusion. Also consider commits b840508644 and
bcb14f4abc.
I had tried to come up with a narrower fix, and I think it's
On Tue, Apr 09, 2024 at 06:24:43PM -0700, Jeff Davis wrote:
> I had suggested that the heap could track the element indexes for
> efficient update/removal, but that would be a change to the
> binaryheap.h API, which would require some discussion (and possibly not
> be acceptable post-freeze).
>
>
On Tue, Apr 9, 2024 at 2:47 AM Robert Haas wrote:
>
> - I'm slightly worried about the TID store work (ee1b30f12, 30e144287,
> 667e65aac35), perhaps for no reason. Actually, the results seem really
> impressive,
First, thanks for the complement. I actually suspect if we had this
years ago, it
Hi
PostgreSQL 18 will ship after these vacuum horizon systems reach EOL[1]:
animal | arch | llvm_version | os | os_release | end_of_support
---+-+--+++
branta | s390x | 10.0.0 | Ubuntu | 20.04 | 2025-04-01
splitfin | aarch64 |
On Tue, 2024-04-09 at 23:49 +0300, Heikki Linnakangas wrote:
>
> I wonder why this doesn't use the existing pairing heap
> implementation? I would assume that to be at least as good as the
> binary
> heap + hash table
I agree that an additional hash table is not needed -- there's already
a
On Wed, 10 Apr 2024 at 10:24, David Rowley wrote:
> Master failed today for the first time since the compiler upgrade.
> Again reltuples == 48.
>From the buildfarm members page, parula seems to be the only aarch64 + gcc
13.2
combination today, and then I suspect whether this is about gcc v13.2
Andres Freund writes:
> On 2024-04-09 20:12:48 -0400, Tom Lane wrote:
>> In any case, this is all moot unless we can come to a new design for
>> how ecpg does its string-mashing. Thoughts?
> Am I missing something, or is ecpg string handling almost comically
> inefficient? Building up strings
On Tue, 9 Apr 2024 at 15:48, David Rowley wrote:
> Still no partition_prune failures on master since the compiler version
> change. There has been one [1] in REL_16_STABLE. I'm thinking it
> might be worth backpatching the partition_prune debug to REL_16_STABLE
> to see if we can learn anything
On Tue, Apr 9, 2024 at 10:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> + /* In assertion builds, run the LLVM verify pass. */
> +#ifdef USE_ASSERT_CHECKING
> + LLVMPassBuilderOptionsSetVerifyEach(options, true);
> +#endif
Thanks, that seems
Hi,
On 2024-04-09 20:12:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, just redefining mm_strdup() that way doesn't help much here either,
> > even with an affected compiler. The gain increases substantially after
> > simplifying unreserved_keyword etc to just use the default
Andres Freund writes:
> On 2024-04-09 19:44:03 -0400, Tom Lane wrote:
>> As you did, I wasn't trying to get to a working result, so I didn't do
>> anything about removing all the free's or fixing the cast-away-const
>> warnings. The result was disappointing though. On my Mac laptop
>> (Apple
Hi,
On 2024-04-09 19:44:03 -0400, Tom Lane wrote:
> I experimented with replacing mm_strdup() with
>
> #define mm_strdup(x) (x)
>
> As you did, I wasn't trying to get to a working result, so I didn't do
> anything about removing all the free's or fixing the cast-away-const
> warnings. The result
On Tue, 9 Apr 2024 at 16:18, David Rowley wrote:
> There's just 1 instance of "a SQL" that crept into PG16 after
> d866f0374. This probably means I'd be better off doing this in June a
> few weeks before branching...
>
> Patch attached.
Pushed.
David
On Tue, 9 Apr 2024 at 14:27, Tom Lane wrote:
>
> David Rowley writes:
> > Similar to f736e188c, I've attached a patch that fixes up a few
> > misusages of the StringInfo functions. These just swap one function
> > call for another function that is more suited to the use case.
>
> > I feel like
On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote:
> Even so, only keeping WAL for the last backup is a dangerous move in any
> case. Lots of things can happen to a backup (other than bugs in the
> software) so keeping WAL back to the last full (or for all backups) is
> always an
Andres Freund writes:
> On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Why are strduping all of these?
>> IIRC, the issue is that the mechanism for concatenating the tokens
>> back together frees the input strings
> Ah, that explains it - but also seems somewhat
On Tue, Apr 9, 2024 at 7:35 PM Michael Paquier wrote:
> It's been on my TODO list to automate that in one of my buildfarm
> animals, and never got down to do it. I've looked at the current
> animal fleet, and it looks that we don't have one yet. Perhaps I've
> just missed something?
Hi all,
I have been doing some checks with page masking and WAL consistency
now that we are in feature freeze, and there are no failures on HEAD:
cd src/test/recovery/ && \
PG_TEST_EXTRA=wal_consistency_checking \
PROVE_TESTS=t/027_stream_regress.pl make check
It's been on my TODO list
On 4/10/24 01:59, Andrey M. Borodin wrote:
On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
Maybe we should explicitly advise users to not delete that WAL from
their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box
Hi,
On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we need to do something about the compile time of this file, even
> > with
> > gcc. Our main grammar already is an issue and stacking all the ecpg stuff on
> > top makes it considerably worse.
>
> Seems
Hi,
On 2024-04-09 15:33:10 -0700, Andres Freund wrote:
> Which leads to a control flow graph with *many* incoming edges to the basic
> block containing the function call to mm_strdup(), triggering a normally
> harmless O(N^2) or such.
With clang-16 -O2 there is a basic block with 3904 incoming
On Mon, Apr 8, 2024 at 11:43 PM Dmitry Koval wrote:
> Attached fix for the problems found by Alexander Lakhin.
>
> About grammar errors.
> Unfortunately, I don't know English well.
> Therefore, I plan (in the coming days) to show the text to specialists
> who perform technical translation of
Andres Freund writes:
> I think we need to do something about the compile time of this file, even with
> gcc. Our main grammar already is an issue and stacking all the ecpg stuff on
> top makes it considerably worse.
Seems reasonable, if we can.
> Why are strduping all of these?
IIRC, the
On Wed, Apr 10, 2024 at 12:52:19AM +0300, Kirill Reshke wrote:
> On Tue, 9 Apr 2024 at 08:53, Michael Paquier wrote:
>> The thing is that you cannot rely on a lookup of the backend type for
>> the error information, or you open yourself to letting the caller of
>> pg_cancel_backend or
Hi,
On 2024-04-09 17:13:52 +1200, Thomas Munro wrote:
> On Tue, Apr 9, 2024 at 5:01 PM Michael Paquier wrote:
> > On Mon, Apr 08, 2024 at 12:23:56PM +0300, Nazir Bilal Yavuz wrote:
> > > On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
> > >> As I wrote in [1], I didn't observe the issue
Hi, thanks for looking into this.
On Tue, 9 Apr 2024 at 08:53, Michael Paquier wrote:
> On Mon, Apr 08, 2024 at 05:42:05PM +, Leung, Anthony wrote:
> > Are you suggesting that we check if the backend is B_AUTOVAC in
> > pg_cancel/ terminate_backend? That seems a bit unclean to me since
> >
On Mon, Apr 8, 2024 at 10:41:17AM -0400, Robert Treat wrote:
> Unfortunately many humans are hardwired towards procrastination and
> last minute heroics (it's one reason why deadline driven development
> works even though in the long run it tends to be bad practice), and
> historically was one of
On Mon, Apr 8, 2024 at 09:32:14PM +0200, Jelte Fennema-Nio wrote:
> I'll sketch a situation: There's a big patch that some non-committer
> submitted that has been sitting on the mailinglist for 6 months or
> more, only being reviewed by other non-committers, which the submitter
> quickly
Hi,
On 2024-04-08 22:52:09 -0700, Parag Paul wrote:
> We have an interesting problem, where PG went to PANIC due to stuck
> spinlock case.
> On careful analysis and hours of trying to reproduce this(something that
> showed up in production after almost 2 weeks of stress run), I did some
>
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
>> What exactly is the point of having a NodeTag in the struct though?
>> If you don't need it to be a valid Node, that seems pointless and
>> confusing. We certainly have plenty of other lists that contain
>> plain
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 6:18 PM Robert Haas wrote:
>> I too felt uneasy about that commit, for the same reason. However,
>> there is a justification for the change in the commit message which is
>> not obviously wrong, namely that ":{?name} is the only psql syntax
>>
On 09/04/2024 21:04, Jeff Davis wrote:
On Fri, 2024-04-05 at 16:58 +0900, Masahiko Sawada wrote:
I have some further comments and I believe changes are required for
v17.
I also noticed that the simplehash is declared in binaryheap.h with
"SH_SCOPE extern", which seems wrong. Attached is a
On Tue, Apr 9, 2024 at 11:42 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> >> Yeah, that's one of the reasons I'm dubious that the committed
> >> patch was ready.
>
> > While inventing this GUC, I was thinking more about avoiding
> >
On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> >> * OrClauseGroupKey is not a Node type, so why does it have
> >> a NodeTag? I wonder what value will appear in that field,
> >> and what will happen if the struct
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
>> Yeah, that's one of the reasons I'm dubious that the committed
>> patch was ready.
> While inventing this GUC, I was thinking more about avoiding
> regressions rather than about unleashing the full power of this
>
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
>> * OrClauseGroupKey is not a Node type, so why does it have
>> a NodeTag? I wonder what value will appear in that field,
>> and what will happen if the struct is passed to any code
>> that expects real Nodes.
> I
Robert Haas writes:
> On Tue, Apr 9, 2024 at 3:44 PM Tom Lane wrote:
>> The usual gotchas apply: you need to have started the postmaster
>> under "ulimit -c unlimited", and the /cores directory has to be
>> writable by whatever user the postmaster is running as. I have
>> occasionally seen
On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> >> I don't know that I'd call it scary exactly, but I do think it
> >> was premature. A week ago there was no consensus that it was
> >> ready to commit, but Alexander
On Tue, Apr 9, 2024 at 8:37 AM Andrei Lepikhov
wrote:
> On 9/4/2024 09:12, Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR clauses to ANY
On Tue, Apr 9, 2024 at 3:44 PM Tom Lane wrote:
> Works for me on Sonoma 14.4.1 and Ventura 13.6.6, and has done
> in many versions before those.
>
> The usual gotchas apply: you need to have started the postmaster
> under "ulimit -c unlimited", and the /cores directory has to be
> writable by
On Tue, Apr 9, 2024 at 3:33 PM Jeff Davis wrote:
> Should I go ahead and commit something like that now, or hold it until
> the other thread concludes, or hold it until the July CF?
I think it's fine to commit it now if it makes it usefully easier to
fix an open item, and otherwise it should
On Tue, Apr 9, 2024 at 3:30 PM Jeff Davis wrote:
> Pages of warnings is not ideal, though. We should either support
> "SH_SCOPE static", or have some kind of useful #error that makes it
> clear that we don't support it (and/or don't think it's a good idea).
Fair.
> > I'm not sure that I like
On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> * OrClauseGroupKey is not a Node type, so why does it have
> a NodeTag? I wonder what value will appear in that field,
> and what will happen if the struct is passed to any code
> that expects real Nodes.
I used that to put both
Robert Haas writes:
> On Tue, Apr 9, 2024 at 2:37 PM Tom Lane wrote:
>> Still works for me, at least on machines where I have SIP turned
>> off. Admittedly, Apple's busy making that a less and less desirable
>> choice.
> What exact version are you running?
Works for me on Sonoma 14.4.1 and
Hi,
On Tue, 2024-04-09 at 11:56 -0700, Andres Freund wrote:
> FWIW, with just about any modern-ish compiler just using "inline"
> doesn't
> actually force inlining, it just changes the cost model to make it
> more
> likely.
OK.
In the linked thread, I didn't see a good reason to encourage the
On Tue, 2024-04-09 at 14:49 -0400, Robert Haas wrote:
> Hmm. I'm pretty sure that I've run into this problem, but I concluded
> that I should use either "static inline" or "extern" and didn't think
> any more of it.
Pages of warnings is not ideal, though. We should either support
"SH_SCOPE
On Tue, Apr 9, 2024 at 8:55 AM Tom Lane wrote:
> Andrei Lepikhov writes:
> > On 9/4/2024 09:12, Tom Lane wrote:
> >> I have another one that I'm not terribly happy about:
> >> Author: Alexander Korotkov
> >> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >> Transform OR clauses to
Hi,
On 2024-04-09 11:10:15 -0700, Jeff Davis wrote:
> The reason I'm suggesting it there is because the hash table is used
> only for the indexed binary heap, not an ordinary binary heap, so I'd
> like to leave it up to the compiler whether to do any inlining or not.
FWIW, with just about any
On Tue, Apr 9, 2024 at 2:10 PM Jeff Davis wrote:
> If using "SH_SCOPE static" with simplehash.h, it causes a bunch of
> warnings about functions that are defined but not used. It's simple
> enough to fix by appending pg_attribute_unused() to the declarations
> (attached).
Hmm. I'm pretty sure
On Tue, Apr 9, 2024 at 2:37 PM Tom Lane wrote:
> Robert Haas writes:
> > At least not for me. According to various things I found on the
> > Internet, it's now required that you codesign your binaries and give
> > them an entitlement in order to generate core dumps:
>
> Still works for me, at
Robert Haas writes:
> At least not for me. According to various things I found on the
> Internet, it's now required that you codesign your binaries and give
> them an entitlement in order to generate core dumps:
Still works for me, at least on machines where I have SIP turned
off. Admittedly,
On Tue, Apr 9, 2024 at 6:18 PM Robert Haas wrote:
> On Thu, Apr 4, 2024 at 10:38 PM Michael Paquier wrote:
> > > It kind of looks like a libedit bug, but maybe we should dig more
> > > deeply. I felt itchy about 927332b95e77 removing '{' from the
> > > WORD_BREAKS set, and wondered exactly how
If using "SH_SCOPE static" with simplehash.h, it causes a bunch of
warnings about functions that are defined but not used. It's simple
enough to fix by appending pg_attribute_unused() to the declarations
(attached).
There are currently no callers that use "SH_SCOPE static", but I'm
suggesting its
On Fri, 2024-04-05 at 16:58 +0900, Masahiko Sawada wrote:
> > I have some further comments and I believe changes are required for
> > v17.
I also noticed that the simplehash is declared in binaryheap.h with
"SH_SCOPE extern", which seems wrong. Attached is a rough patch to
bring the declarations
Hi,
Looks like I forgot to update the thread to note that I finally committed the
remaining warning fixes. I had already fixed a bunch of others in upstream
meson.
commit a3da95deee38ee067b0bead639c830eacbe894d5
Author: Andres Freund
Date: 2024-03-13 01:40:53 -0700
meson: macos: Avoid
Hi,
On 2024-04-09 13:35:51 -0400, Robert Haas wrote:
> Now, if DYLD_* is ignored, then our regression tests won't work
> properly. But if core dumps are not enabled, then how am I supposed to
> debug things that can only be debugged with a core dump?
FWIW, I posted a patch a while back to make
At least not for me. According to various things I found on the
Internet, it's now required that you codesign your binaries and give
them an entitlement in order to generate core dumps:
https://nasa.github.io/trick/howto_guides/How-to-dump-core-file-on-MacOS.html
But according to previous
On 2024-Mar-29, Tender Wang wrote:
> I think aboved case can explain what's meaning about comments in
> dropconstraint_internal.
> But here, in RemoveConstraintById() , we only care about primary key case,
> so NOT NULL is better to removed from comments.
Actually, I think it's better if all the
> On 4 Apr 2024, at 23:46, Daniel Gustafsson wrote:
>
>> On 4 Apr 2024, at 23:24, Tom Lane wrote:
>
>> A minimum fix that seems to make this work better is as attached,
>> but I feel like somebody ought to examine all the IPC::Run::timer
>> and IPC::Run::timeout calls and see which ones are
On Mon, Apr 8, 2024 at 10:24 PM Michael Paquier wrote:
> At the end, having a way to generate JSON blobs randomly to test this
> stuff would be more appealing
For the record, I'm working on an LLVM fuzzer target for the JSON
parser. I think that would be a lot more useful than anything we can
On Tue, Apr 9, 2024 at 12:27 PM Tom Lane wrote:
> > Some of the most compelling cases for the transformation will involve
> > path keys. If the transformation enables the optimizer to build a
> > plain index scan (or index-only scan) with useful path keys, then that
> > might well lead to a far
Peter Geoghegan writes:
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
>> I don't know that I'd call it scary exactly, but I do think it
>> was premature. A week ago there was no consensus that it was
>> ready to commit, but Alexander pushed it (or half of it, anyway)
>> despite that.
>
On Tue, Apr 9, 2024 at 7:30 AM Andrew Dunstan wrote:
> I think Michael's point was that if we carry the code we should test we
> can run it. The other possibility would be just to remove it. I can see
> arguments for both.
Hm. If it's not acceptable to carry this (as a worse-is-better smoke
On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> I don't know that I'd call it scary exactly, but I do think it
> was premature. A week ago there was no consensus that it was
> ready to commit, but Alexander pushed it (or half of it, anyway)
> despite that.
Some of the most compelling cases
> On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
>
> Maybe we should explicitly advise users to not delete that WAL from
> their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Postgres
tools as some bulletproof
On 2024-Apr-09, Stefan Fercot wrote:
> At some point, the only way to really validate a backup is to actually try to
> restore it.
> And if people get encouraged to do that faster thanks to incremental backups,
> they could detect potential issues sooner.
> Ultimately, users will still need
On Thu, Apr 4, 2024 at 10:38 PM Michael Paquier wrote:
> > It kind of looks like a libedit bug, but maybe we should dig more
> > deeply. I felt itchy about 927332b95e77 removing '{' from the
> > WORD_BREAKS set, and wondered exactly how that would change readline's
> > behavior. But even if
On Tue, Apr 9, 2024 at 12:19 AM Thomas Munro wrote:
> This idea is due to Robert Haas, who complained that he feared that
> the streaming I/O API already worked like this. It doesn't, but it
> could! Here is a concept patch to try it out.
Oh, no, it's all my fault!
My favorite part of this
On 2024-04-09 Tu 09:45, Jacob Champion wrote:
On Tue, Apr 9, 2024 at 4:54 AM Andrew Dunstan wrote:
On 2024-04-09 Tu 01:23, Michael Paquier wrote:
There is no direct check on test_json_parser_perf.c, either, only a
custom rule in the Makefile without specifying something for meson.
So it
On 2024-04-09 Tu 09:46, Tom Lane wrote:
Michael Paquier writes:
By the way, are you planning to do something like [1]? I've not
looked in details at the callers of IPC::Run::timeout, still the extra
debug output would be nice.
It needs more review I think - I didn't check every call site
Michael Paquier writes:
> By the way, are you planning to do something like [1]? I've not
> looked in details at the callers of IPC::Run::timeout, still the extra
> debug output would be nice.
It needs more review I think - I didn't check every call site to see
if anything would be broken. I
On Tue, Apr 9, 2024 at 4:54 AM Andrew Dunstan wrote:
> On 2024-04-09 Tu 01:23, Michael Paquier wrote:
> There is no direct check on test_json_parser_perf.c, either, only a
> custom rule in the Makefile without specifying something for meson.
> So it looks like you could do short execution check
Hi,
On Tuesday, April 9th, 2024 at 2:46 PM, Robert Haas
wrote:
> In all sincerity, I appreciate the endorsement. Basically what's been
> scaring me about this feature is the possibility that there's some
> incurable design flaw that I've managed to completely miss. If it has
> some more
On 9/4/2024 12:55, Tom Lane wrote:
Andrei Lepikhov writes:
* I really, really dislike jamming this logic into prepqual.c,
where it has no business being. I note that it was shoved
into process_duplicate_ors without even the courtesy of
expanding the header comment:
Yeah, I preferred to do
On Thursday, April 4, 2024 4:25 PM Masahiko Sawada
wrote:
Hi,
> On Wed, Apr 3, 2024 at 7:06 PM Amit Kapila
> wrote:
> >
> > On Wed, Apr 3, 2024 at 11:13 AM Amit Kapila
> wrote:
> > >
> > > On Wed, Apr 3, 2024 at 9:36 AM Bharath Rupireddy
> > > wrote:
> > >
> > > > I quickly looked at v8,
On Tue, Apr 9, 2024 at 7:24 AM Tomas Vondra
wrote:
> I think it's a bit more nuanced, because it's about backups/restore. The
> bug might be subtle, and you won't learn about it until the moment when
> you need to restore (or perhaps even long after that). At which point
> "You might have taken
On 4/8/24 22:57, Bruce Momjian wrote:
On Sat, Mar 30, 2024 at 04:50:26PM -0400, Robert Haas wrote:
An awful lot of what we do operates on the principle that we know the
people who are involved and trust them, and I'm glad we do trust them,
but the world is full of people who trusted somebody
On Tue, 9 Apr 2024 at 13:12, 范润泽 wrote:
>
> Hi, Hackers
> I have observed that there has been a paucity of discussion concerning the
> parallel replay of WAL logs.
> The most recent discourse on this subject was during the PGCon event in 2023,
> where it was noted that PostgreSQL utilizes a
On 2024-04-08 Mo 19:26, Tom Lane wrote:
Andrew Dunstan writes:
I quite like the triage idea. But I think there's also a case for being
more a bit more flexible with those patches we don't throw out. A case
close to my heart: I'd have been very sad if the NESTED piece of
JSON_TABLE hadn't
Em seg., 8 de abr. de 2024 às 09:27, Jelte Fennema-Nio
escreveu:
> On Sun, 7 Apr 2024 at 11:34, David Rowley wrote:
> > That seems to require modifying the following function signatures:
> > secure_write(), be_tls_write(), be_gssapi_write(). That's not an area
> > I'm familiar with, however.
>
On 2024-04-09 Tu 01:23, Michael Paquier wrote:
On Tue, Apr 09, 2024 at 09:48:18AM +0900, Michael Paquier wrote:
There is no direct check on test_json_parser_perf.c, either, only a
custom rule in the Makefile without specifying something for meson.
So it looks like you could do short execution
On Tue, Mar 07, 2023 at 12:15:27AM -0500, Tom Lane wrote:
> "David G. Johnston" writes:
> > As an aside, for anyone more fluent than I who reads this, is the use of
> > the word "dynamic scale" in this code comment supposed to be "display
> > scale"?
> >
Hi,
On Tue, Apr 9, 2024 at 4:47 PM jian he wrote:
>
> hi.
> `
> | NESTED [ PATH ] json_path_specification [ AS json_path_name ]
> COLUMNS ( json_table_column [, ...] )
> NESTED [ PATH ] json_path_specification [ AS json_path_name ] COLUMNS
> ( json_table_column [, ...] )
> `
>
On 4/9/24 01:33, Michael Paquier wrote:
> On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
>> I don't feel too particularly worried about this. Yes, backups are super
>> important because it's often the only thing you have left when things go
>> wrong, and the incremental aspect is
Hi, Hackers
I have observed that there has been a paucity of discussion concerning the
parallel replay of WAL logs.
The most recent discourse on this subject was during the PGCon event in 2023,
where it was noted that PostgreSQL utilizes a single process for WAL replay.
However, when
On Thu, 4 Apr 2024 at 16:58, Jelte Fennema-Nio wrote:
> > ISTM that with a small shell script, .editorconfig could be generated
> > from .gitattributes?
>
> Honestly, I don't think building such automation is worth the effort.
Okay, I spent the time to add a script to generate the editorconfig
Dear Michael,
> On Fri, Apr 05, 2024 at 06:22:58AM +, Hayato Kuroda (Fujitsu) wrote:
> > Thanks for pointing out. Yes, we fixed a behavior by the commit aa5edbe37,
> > but we missed the redo case. I made a fix patch based on the suggestion [1].
>
> + boolmod_buf = false;
>
>
On 4/9/24 11:25, Matthias van de Meent wrote:
> On Mon, 8 Apr 2024 at 20:15, Tomas Vondra
> wrote:
>>
>>
>> On 4/8/24 17:48, Matthias van de Meent wrote:
>>> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra
>>> wrote:
Maybe it'd be better to start by expanding the existing rule about not
> On Tue, Apr 09, 2024 at 07:07:58PM +1200, Thomas Munro wrote:
> On Sat, Apr 6, 2024 at 5:01 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > > > Yep, I think this is it. I've spent some hours trying to understand why
> > > > suddenly deform function has noundef ret attribute, when it
In b262ad440e we introduced an optimization that drops IS NOT NULL quals
on a NOT NULL column, and reduces IS NULL quals on a NOT NULL column to
constant-FALSE. I happened to notice that this is not working correctly
for traditional inheritance parents. Traditional inheritance parents
might have
On 4/9/24 09:59, Martín Marqués wrote:
> Hello,
>
> While doing some work/research on the new incremental backup feature
> some limitations were not listed in the docs. Mainly the fact that
> pg_combienbackup works with plain format and not tar.
>
Right. The docs mostly imply this by talking
1 - 100 of 112 matches
Mail list logo
