On Sun, 2025-02-23 at 22:23 -0500, Andy Alsup wrote:
> Please find the attached patch files that supersede the previous email.
>
> Patch 0001 contains some modest modifications to the UUID data type docs
> (Section 8.12. UUID Type). The main goal is to inform the reader that there
> are multiple
On Sat, Feb 22, 2025 at 11:12 PM Richard Guo wrote:
>
> On Sat, Feb 22, 2025 at 11:55 PM Richard Guo wrote:
> > Attached are the updated patches to fix all the mentioned issues. I
> > plan to push them early next week after staring at the code for a bit
> > longer, barring any objections.
>
> Si
On Sun, 2025-02-23 at 20:03 -0500, Corey Huinker wrote:
> If we're fine with giving up on appendNamedArgument() for relstats,
> wouldn't we also want to mash these into a single call?
...
> appendPQExpBuffer(out, "\t'relation', '%s'::regclass"
> ",\n\t'version', '%u'::integ
po 24. 2. 2025 v 6:16 odesílatel Tom Lane napsal:
> "David G. Johnston" writes:
> > How about:
> > \pset partition_roots_only 'true'
>
> FWIW, I don't especially love this idea. None of our existing
> \d-type commands use pset parameters for filtering, and I don't
> see a reason to believe that
Hello hackers!
> I think the overall idea here is good, but I didn't like the new
> WriteSlruZeroPageXlogRec helper function; it looks too much like a
> modularity violation (same for the fact that you have to pass the rmid
> and info from each caller into slru.c). I would not do that in slru.c
>
On Tue, Feb 18, 2025 at 12:16 AM Shubham Khanna
wrote:
>
-static void check_publisher(const struct LogicalRepInfo *dbinfo);
-static char *setup_publisher(struct LogicalRepInfo *dbinfo);
+static void check_publisher(const struct LogicalRepInfo *dbinfo, bool
two_phase);
+static char *setup_publishe
"David G. Johnston" writes:
> How about:
> \pset partition_roots_only 'true'
FWIW, I don't especially love this idea. None of our existing
\d-type commands use pset parameters for filtering, and I don't
see a reason to believe that people would typically want this
to be a persistent setting. I'
Hi Jacob,
Thanks a lot for this! We have been trying to come up with a similar
feature for the new commitfest app [0].
> If we like this, I'm happy to help port a version of it over to the
commitfest app.
I would love to help you out in porting this to the commitfest app.
Regards,
Akshat Jaimin
On Tue, Feb 18, 2025 at 1:11 AM Masahiko Sawada wrote:
>
> Right. I'm inclined to support only the second heap pass as the first
> step. If we support parallelism only for the second pass, it cannot
> help speed up freezing the entire table in emergency situations, but
> it would be beneficial for
Hi all,
I have created an experimental tool [0] to help explore the vast depths of
the upcoming commitfest, and it's designed to help each contributor find
actually useful and relevant patches to review. Please have a look!
Under the hood, it does two things:
1. Use a good LLM [1] to analyze all
wenhui qiu writes:
>I found this path https://commitfest.postgresql.org/patch/3235/ already
> supports anti join , But I've found that in many cases it doesn't work.It
> always uses SubPlan Here's my testing process.
NOT IN is not convertible to an anti-join: the semantics are wrong
because o
wenhui qiu 于2025年2月24日周一 09:48写道：
> Hi Richard Guo
>I found this path https://commitfest.postgresql.org/patch/3235/
> already supports anti join , But I've found that in many cases it doesn't
> work.It always uses SubPlan Here's my testing process.
>
> ###
> create table join1 (id int
Please find the attached patch files that supersede the previous email.
Patch 0001 contains some modest modifications to the UUID data type docs
(Section 8.12. UUID Type). The main goal is to inform the reader that there
are multiple versions of UUID generation algorithms (presently 8); however,
o
Hi Nisha.
Some review comments for patch v1-0001
==
GENERAL
1.
This may be a basic/naive question, but it is unclear to me why we
care about the stats of confl_multiple_unique_conflicts?
I can understand it would be useful to get multiple conflicts logged
at the same time so the user doesn'
Hi Richard Guo
I found this path https://commitfest.postgresql.org/patch/3235/ already
supports anti join , But I've found that in many cases it doesn't work.It
always uses SubPlan Here's my testing process.
###
create table join1 (id integer,name varchar(300),k1 integer);
create table
Corey Huinker writes:
> If we're fine with giving up on appendNamedArgument() for relstats,
> wouldn't we also want to mash these into a single call?
> appendPQExpBuffer(out, "\t'relation', '%s'::regclass,\n", qualname);
> appendPQExpBuffer(out, "\t'version', '%u'::integer,\n",
> fout->remo
On Sat, Feb 22, 2025 at 04:17:44PM +, David Steele wrote:
> I think for translation purposes this is probably how it needs to be but I
> wonder if we could do something like:
>
> errdetail("Latest checkpoint in %s is at %X/%X <...>",
> haveBackupLabel ? "pg_control" ? "backup_label",
On Sun, Feb 23, 2025 at 7:22 PM Jeff Davis wrote:
> On Sat, 2025-02-22 at 00:00 -0500, Corey Huinker wrote:
> >
> > Attached is the first optimization, which gets rid of the pg_class
> > queries entirely, instead getting the same information from the
> > existing queries in getTables and getIndex
On Thu, Feb 20, 2025 at 08:11:12AM +, Bertrand Drouvot wrote:
> LGTM.
Applied this one. Now, to the part about the backend stats and WAL,
which should be the last piece..
--
Michael
signature.asc
Description: PGP signature
On Sun, Feb 23, 2025 at 4:31 PM Greg Sabino Mullane
wrote:
> On Sun, Feb 23, 2025 at 4:34 PM Sadeq Dousti wrote:
>
>> Totally agree about the naming. There's no other terminology known to me,
>> but I'll definitely think about it. Of course, I'm very open to
>> suggestions from you or anyone els
On Sat, 2025-02-22 at 00:00 -0500, Corey Huinker wrote:
>
> Attached is the first optimization, which gets rid of the pg_class
> queries entirely, instead getting the same information from the
> existing queries in getTables and getIndexes.
Attached a revised version. The main changes are that th
On Fri, Feb 21, 2025 at 09:53:06AM -0500, Tom Lane wrote:
> If I have to actually debug or test behavior touching this, I use a
> non-reporting buildfarm instance that I have lying around, which is
> configured to run the cross-version tests and not very much else.
> I can switch that between pulli
>> IMO, the set of cases where it's legitimate to mark individual struct
>> fields as const is negligibly small, and this doesn't seem to be one
>> of them.
>
> Thanks for the report, will fix.
>
>> BTW, as another nitpicky style matter: why do PGoauthBearerRequest
>> etc. spell their struct tag
On Sun, Feb 23, 2025 at 4:34 PM Sadeq Dousti wrote:
> Totally agree about the naming. There's no other terminology known to me,
> but I'll definitely think about it. Of course, I'm very open to
> suggestions from you or anyone else in the community.
>
The problem is that we are really tight on a
On 23/2/2025 22:15, Alexander Korotkov wrote:
There is my attempt to implement this approach. Getting rid of local
variable (and computation of the same value other way) required to
change arguments of remove_rel_from_eclass() as well. I'm going to
further polish this tomorrow.
I passed throug
Sadeq Dousti writes:
>> "High-level" is not terminology we use anywhere else
>> We do use the terms "root partition" or "partition root".
> I agree "high-level" is not standard, but "root partition" also entails
> the table is actually partitioned. This is not necessarily the case.
> The suggeste
> That definition seems bizarre, and even less derivable
> from the term "high-level" than what I thought you meant.
> You really need some other terminology, I think.
Totally agree about the naming. There's no other terminology known to
me, but I'll definitely think about it. Of course, I'm very
Hi Tom,
Thanks a lot for looking into this!
> "High-level" is not terminology we use anywhere else
> We do use the terms "root partition" or "partition root".
I agree "high-level" is not standard, but "root partition" also entails
the table is actually partitioned. This is not necessarily the ca
On Sun, Feb 23, 2025 at 7:02 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > I've corrected some spelling error reported by Alexander Lakhin
> > privately to me. Also, I've revised comments around ChangeVarNodes()
> > and ChangeVarNodesExtended(). I'm going to continue nitpicking this
> >
> Sorry an id was missing in psql documentation, thus CI was failing.
Combining patches into one, as otherwise CI does not combine them.
Best Regards
Sadeq Dousti
From ad81b71fe67174aebd7f6c02a82aa0ab88ff Mon Sep 17 00:00:00 2001
From: Sadeq Dousti <3616518+msdousti@users.noreply.github.com>
Sadeq Dousti writes:
> Please find attached the patch to add a new metacommand (\dh) to psql.
I don't have a strong feeling one way or the other about whether this
is useful functionality or not. But if we do want it, I'd like to
bikeshed on the name a bit. "High-level" is not terminology we us
Sorry an id was missing in psql documentation, thus CI was failing.
Please find attached a patch that fixes this issue.
Best Regards,
Sadeq Dousti
Tech Lead and Staff Software Engineer at Trade Republic Bank GmbH
From c7b7f39c171648f3193cb9d61a4815ac32b779e3 Mon Sep 17 00:00:00 2001
From: Sadeq <3
Dear hackers,
Please find attached the patch to add a new metacommand (\dh) to psql.
I find the functionality very useful for my day-to-day job, and decided
to add it to psql source code. Summary of the command, justification
for adding the functionality, as well as design choices are listed
below
> On 23 Feb 2025, at 17:49, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I spent a few more hours staring at this, and ran it through a number of CI
>> and
>> local builds, without anything showing up. Pushed to master with the first
>> set
>> of buildfarm animals showing green builds.
>
Alexander Korotkov writes:
> I've corrected some spelling error reported by Alexander Lakhin
> privately to me. Also, I've revised comments around ChangeVarNodes()
> and ChangeVarNodesExtended(). I'm going to continue nitpicking this
> patch during next couple days then push it if no objections.
Daniel Gustafsson writes:
> I spent a few more hours staring at this, and ran it through a number of CI
> and
> local builds, without anything showing up. Pushed to master with the first
> set
> of buildfarm animals showing green builds.
Coverity has a nit-pick about this:
/srv/coverity/git/p
On Sat, Feb 8, 2025 at 12:41 AM jian he wrote:
> hi.
> ```
> drop table if exists idxpart;
> create table idxpart (a int, b int, c text) partition by range (a);
> create table idxpart1 (like idxpart);
> alter table idxpart attach partition idxpart1 for values from (0) to (10);
>
> create index id
On Sun Feb 23, 2025 at 3:51 PM CET, Jelte Fennema-Nio wrote:
Attached is an updated patch that fixes the tests and changes the
whitespace as discussed (including removing a spurious second space
before the ON, which I noticed while changing it). As well as a seprate
patch that changes the "c" ali
On Mon Jan 27, 2025 at 8:39 PM CET, Nathan Bossart wrote:
+1
Separately, I see that there's one update needed for
src/test/regress/expected/psql.out. The documentation for \dx looks
generic enough that it probably doesn't need any updates, though.
Attached is an updated patch that fixes the t
I have committed the rest of this with the adjustments you suggested.
On 10.02.25 18:44, Dagfinn Ilmari Mannsåker wrote:
Here is a new patch set rebased over that.
I had a more thorough read-through this time (as well as applying and
building it), and it does make the code a lot more readab
Amit Langote 于2025年2月23日周日 16:36写道：
> On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
> > Alexander Lakhin 于2025年2月22日周六 23:00写道：
> >> 21.02.2025 05:40, Amit Langote wrote:
> >>
> >> I pushed the final piece yesterday.
> >>
> >>
> >> Please look at new error, produced by the following script
> On 23 Feb 2025, at 13:03, Jelte Fennema-Nio wrote:
>
> On Sun, 23 Feb 2025 at 07:49, Kirill Reshke wrote:
>> So, are we +1 or -1 on moving this forward?
>
> +1 from me. Marked as ready for committer.
Agreed, I have it on my TODO for the week to revisit.
./daniel
14.02.2025 11:41, Zhou, Zhiguo пишет:
>
>
> On 2/11/2025 9:25 AM, Japin Li wrote:
>> On Mon, 10 Feb 2025 at 22:12, "Zhou, Zhiguo" wrote:
>>> On 2/5/2025 4:32 PM, Japin Li wrote:
On Mon, 27 Jan 2025 at 17:30, "Zhou, Zhiguo" wrote:
> On 1/26/2025 10:59 PM, Yura Sokolov wrote:
>> 24.0
On Sun, 23 Feb 2025 at 07:49, Kirill Reshke wrote:
> So, are we +1 or -1 on moving this forward?
+1 from me. Marked as ready for committer.
This was very painful to read. +1 on making changes. Both for a
culture change to require less urgency over the weekend if it's a
minor failure, and probably also a tooling change to make this less of
a problem in general.
On Sat, 22 Feb 2025 at 04:38, Robert Haas wrote:
>
> On Fri, Feb 21, 2025
On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
> Alexander Lakhin 于2025年2月22日周六 23:00写道：
>> 21.02.2025 05:40, Amit Langote wrote:
>>
>> I pushed the final piece yesterday.
>>
>>
>> Please look at new error, produced by the following script,
>> starting from 525392d57:
>> CREATE TABLE t(id int
46 matches
Mail list logo
