On Sat, Apr 05, 2025 at 07:14:27PM +0900, Michael Paquier wrote:
> On Wed, Apr 02, 2025 at 05:29:00PM -0700, Noah Misch wrote:
>> Your back-patches are correct. Thanks.
>
> Thanks for double-checking. I'll move on with what I have after a
> second look as it's been a few weeks since I've looked
On Sat, Apr 05, 2025 at 10:32:40PM -0400, Andres Freund wrote:
> I think this would all be a nice argument to have when introducing a new
> function. But I don't think it's a wart sufficiently big to justify breaking
> compatibility.
Yeah, I would side as well with the compatibility argument on th
On Sat, Apr 5, 2025 at 1:32 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-04-04 14:34:53 -0700, Masahiko Sawada wrote:
> > On Fri, Apr 4, 2025 at 11:05 AM Melanie Plageman
> > wrote:
> > >
> > > On Tue, Apr 1, 2025 at 5:30 PM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > > > I've attached the
Hi
I've been giving this some final polish which have me time to think it through,
and I think Peter is right. We should not be adding the new column, but instead
RelationBuildTupleDesc should use its existing scan of pg_constraint to
determine validity status of constraints. We may need in add
Hi,
I find that the postgresql.conf.sample file doesn't contain
enable_self_join_elimination guc.
If this is necessary, please see the attached patch.
--
Thanks, Tender Wang
From f27c99aebbd07d4008173492c7913749b149b540 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Sun, 6 Apr 2025 11:54:49 +0
Hi,
On 2025-04-05 12:46:37 -0400, Tom Lane wrote:
> 1. Invent a way to make a particular memory context read-only
> after putting some data into it.
>
> 2. In debug builds, after we've built a tree that should be considered
> read-only, copy it into such a context and make it read-only. Or
> per
Hi,
On 2025-04-04 11:55:41 -0500, Sami Imseih wrote:
> > > > Should the pg_log_ prefix strictly refer to functions that write to
> > > > logs?
> > > >
> > >
> > > I don't know how strict we should be about this,
> >
> > I don't know as well and specially given that:
> >
> > - the snapshot is logge
On Sun, Apr 06, 2025 at 07:42:02AM +0900, Michael Paquier wrote:
> On Sat, Apr 05, 2025 at 12:13:39PM -0700, Noah Misch wrote:
> > Since the 2025-02 releases made non-toy-size archive recoveries fail easily,
> > that's not enough. If the proposed 3-second test is the wrong thing, what
> > instead?
I took another look at this patch, and I still can't persuade
myself that a good case has been made for it. There are too
many scenarios where pg_manage_extensions would be a security
problem and too few where it seems to really improve manageability.
As an example, it was asserted upthread that
Hi,
On 2025-04-05 18:29:22 -0400, Andres Freund wrote:
> I think one thing that the docs should mention is that calling the numa
> functions/views will force the pages to be allocated, even if they're
> currently unused.
>
> Newly started server, with s_b of 32GB an 2MB huge pages:
>
> grep ^H
On Sat, Apr 05, 2025 at 12:13:39PM -0700, Noah Misch wrote:
> Since the 2025-02 releases made non-toy-size archive recoveries fail easily,
> that's not enough. If the proposed 3-second test is the wrong thing, what
> instead?
I don't have a good idea about that in ~16, TBH, but I am sure to not
b
Hi,
I just played around with this for a bit. As noted somewhere further down,
pg_buffercache_numa.page_num ends up wonky in different ways for the different
pages.
I think one thing that the docs should mention is that calling the numa
functions/views will force the pages to be allocated, even
On 4/3/25 11:29 PM, Noah Misch wrote:
Pushed (e.g. v16 has commit 82a8f0f). Only v16 had libpq-be-fe-helpers.h at
all, so I also back-patched 28a5917 to add it. The original use case for
libpq-be-fe-helpers.h was interrupting PQconnectdbParams(), commit e460248. I
decided not to back-patch tha
On 05.04.2025 13:09, Alexander Korotkov wrote:
On Fri, Apr 4, 2025 at 11:35 AM Andrei Lepikhov wrote:
On 4/4/25 04:53, Richard Guo wrote:
On Fri, Apr 4, 2025 at 1:02 AM Alexander Korotkov wrote:
I've got an off-list bug report from Alexander Lakhin involving a
placeholder variable. Alena an
On Wed, Apr 2, 2025 at 10:53 PM Sami Imseih wrote:
> > That seems like a very good location for this advice. But the current
> > set of bullet points are all directed towards "... a general procedure
> > for determining which indexes to create". I propose that a new paragrph,
> > not a bullet poi
Erik Wienhold writes:
> [ v6 patches ]
A couple of drive-by comments:
* I think the proposal to deprecate IF NOT EXISTS is a nonstarter.
Yeah, I don't like it much, but the standard of proof to remove
features is amazingly high and I don't think it's been reached here.
We're unlikely to remove I
Hi,
On 2025-04-04 14:34:53 -0700, Masahiko Sawada wrote:
> On Fri, Apr 4, 2025 at 11:05 AM Melanie Plageman
> wrote:
> >
> > On Tue, Apr 1, 2025 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I've attached the new version patch. There are no major changes; I
> > > fixed some typos, imp
On 05/04/2025 00:29, Thom Brown wrote:
On Fri, 27 Dec 2024 at 08:26, Kyotaro Horiguchi wrote:
Hello. This is the updated version.
(Sorry for the delay; I've been a little swamped.)
- Undo logs are primarily stored in a fixed number of fixed-length
slots and are spilled into files under so
On Fri, Apr 4, 2025 at 5:35 PM Masahiko Sawada wrote:
>
> > I haven't looked closely at this version but I did notice that you do
> > not document that parallel vacuum disables eager scanning. Imagine you
> > are a user who has set the eager freeze related table storage option
> > (vacuum_max_eage
Hello Tom and Corey,
[...] Anyway, my feeling about it is that \copy parsing is a huge hack
right now, and I'd rather see it become less of a hack, that is
more like other psql commands, instead of getting even hackier.
After giving it some thoughts, I concluded that trying to salvage \copy
i
Dmitrii Bondar writes:
> On 04/04/2025 01:11, Tom Lane wrote:
>> So that's a long laundry list and we haven't even dug hard.
>> Is it worth it? If you feel like doing the legwork then
>> I'm willing to support the project, but I really wonder if
>> we shouldn't cut our losses and just remove the
> On 2 Apr 2025, at 23:44, Daniel Gustafsson wrote:
> I think this version is close to a committable state, will spend a little more
> time testing, polishing and rewriting the commit message. I will also play
> around with placement within the memory context code files to keep it from
> making
On Sat, Apr 05, 2025 at 11:07:13AM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Apr 02, 2025 at 05:29:00PM -0700, Noah Misch wrote:
> >> Here it is. Making it fail three times took looping 1383s, 5841s, and
> >> 2594s.
> >> Hence, it couldn't be expected to catch the regression b
Hi!
On 05.04.2025 06:11, Fujii Masao wrote:
Thanks for checking! Barring any objections, I'll go ahead and commit the patch.
As for me all is ok. Thanks!
Maybe extend this to perl tests since there are several hardcoded names too?
The patch attached tries to do this.
I had the same thoug
> > FWIW, I have been thinking about auto_explain for another task,
> > remote plans for fdw [0], and perhaps there are now other good
> > reasons, some that you mention, that can be simplified if "auto_explain"
> > becomes a core feature. This could be a proposal taken up in 19.
>
> For what we're
Hi Heikki,
Please find the attached patch addressing the provided comments. Our responses
are outlined below.
>> - src/backend/port/aix/mkldexport.sh>
> Oh, that's interesting. So if we do that, we don't need mkldepxort.sh
> anymore?
Here the better approach still would be to use the script to e
Hi!
My colleague reviewed my patch and gave feedback on how to improve it -
for some queries with data types that I did not consider, pull-up is not
applied, although it should. Some of them:
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF, BUFFERS OFF)
SELECT 1
FROM ta
WHERE EXISTS (
Hi hackers,
Thanks to David [0], we found that the if and else branches contained
equivalent code. Since ExplainPropertyText already handles non-text
formats, the extra condition is unnecessary.
I reviewed other files related to EXPLAIN where similar patterns might
exist, but this was the on
On Wed, 2 Apr 2025 at 00:51, David Geier wrote:
> The hashed IN optimization is only applied to the first encountered
> ScalarArrayOpExpr during the expression tree traversal in
> convert_saop_to_hashed_saop_walker(). Reason being that the walker
> returns true which aborts the traversal.
> I've
Thanks!
I've pushed the first two parts, improving the shmem accounting.
I've done a couple additional adjustments before commit, namely:
1) I've renamed hash_get_init_size() to just hash_get_size(). We've not
indicated that it's "initial" allocation before, I don't think we need
to indicate to
On 2025-Mar-21, jian he wrote:
> * if partitioned table have valid not-null, then partition with
> invalid not-null can not attach to the partition tree.
Correct.
> if partitioned table have not valid not-null, we *can* attach a
> valid not-null to the partition tree.
Also correct.
> (inhe
On Mon, Mar 31, 2025 at 1:42 PM Yura Sokolov wrote:
> 14.03.2025 17:30, Tomas Vondra wrote:
> > Hi,
> >
> > I've briefly looked at this patch this week, and done a bit of testing.
> > I don't have any comments about the correctness - it does seem correct
> > to me and I haven't noticed any crashes
Hi!
I've reviewed the latest version of the patches and found a few things
worth
discussing. This is probably my final feedback on the patches at this
point.
Maybe Joseph has something to add.
After this discussion, I think it would be helpful if one of the more
experienced
hackers could tak
Hi,
On Tue, Mar 18, 2025 at 07:14:12PM +0800, Xuneng Zhou wrote:
> Hi,
>
> I performed some tests using elog
Thanks for the testing!
> (no so sure whether this is the proper way
> to do it) to monitor the new method.
Well that simple enough and that works well if the goal is just to "count" ;-
On Mon, 24 Mar 2025 at 19:50, Tender Wang wrote:
>
> David Rowley 于2025年3月24日周一 05:28写道：
>> This is no longer true in master, so if we do something here it's only
>> v17 and earlier.
>
> In the case of [1], we still have AccessShareLock on entity_2, even though it
> is pruned during initial part
Hi,
I updated the patch with the following changes:
- Remove the assertion from smgrtruncate() - it would need to assert that it's
called in a critical section.
Not sure why it's not already asserting that?
The function header says:
* ... This function should normally
* be called in
Hi,
On 2025-04-03 16:16:50 -0300, Ranier Vilela wrote:
> Em qui., 3 de abr. de 2025 às 15:35, Andres Freund
> escreveu:> > On 2025-04-03 13:46:39 -0300, Ranier Vilela wrote:
> > > Em qua., 2 de abr. de 2025 às 08:58, Andres Freund
> > > escreveu:
> > >
> > > > Hi,
> > > >
> > > > I've pushed fix
On 01/04/2025 21:25, Heikki Linnakangas wrote:
On 07/03/2025 13:30, Maxim Orlov wrote:
Here is a rebase, v14.
Thanks! I did some manual testing of this. I created a little helper
function to consume multixids, to test the autovacuum behavior, and
found one issue:
Forgot to attach the test
On Sat, Mar 29, 2025 at 1:38 AM Kirill Reshke wrote:
> On Fri, 28 Mar 2025 at 15:19, Richard Guo wrote:
> > On Fri, Mar 28, 2025 at 4:53 PM Kirill Reshke
> > wrote:
> > > On Fri, 28 Mar 2025 at 09:47, jian he wrote:
> > > > The first "Also ignore if NO INHERIT and we weren't told that that's
>
Richard Guo writes:
> On Fri, Feb 21, 2025 at 7:04 PM Ilia Evdokimov
> wrote:
>> When calculating selectivity for an inner equijoin, we call
>> eqjoinsel_inner, which uses unused parameters vardata1 and vardata2.
>> These parameters might have been left behind accidentally when we moved
>> gettin
On Wed, Mar 19, 2025 at 5:26 AM Andrey Borodin wrote:
>
> So, yes, your change to the test seems correct to me. We can do the test with
> just one injection point.
Attached 0001 is what I plan to commit first thing tomorrow morning. I
moved the vacuum_delay_point() so that we would call
pgstat_p
On Fri, Mar 21, 2025 at 02:45:09PM +0900, Michael Paquier wrote:
> Potential ideas about optimizing the branches seem worth
> investigating, I am not sure that I would be able to dig into that
> until the feature freeze gong, unfortunately, and it would be nice to
> fix this issue for this release.
On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
wrote:
> Hello
>
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
>
>
That reloption is already an enum and there is no GUC to defer to when the
va
Hi,
I was away for the last few weeks when this feature got committed, so
I missed the chance to post my comments earlier.
It seems the final SGML docs are mostly from this [1] suggestion, but
I think there are one or two more improvements that can be made to it:
==
1.
It is not at all obvi
On 2025-Mar-28, Ashutosh Bapat wrote:
> However, it's a very painful process to come up with the schedule and
> more painful and error prone to maintain it. It could take many days
> to come up with the right schedule which can become inaccurate the
> moment next SQL file is added OR an existing f
Hi,
I came across date information from an external data source where the
month number is zero-based (January = 0, December = 11) and found that
I couldn't process it directly using the TO_DATE function.
This patch introduces a new pattern (MZ) for handling zero-based
months in Date/Time Formattin
On 13.03.2025 09:42, Bertrand Drouvot wrote:
Hi,
On Wed, Mar 12, 2025 at 05:15:53PM -0500, Jim Nasby wrote:
The usecase I can see here is that we don't want autovac creating so much
WAL traffic that it starts forcing other backends to have to write WAL out.
But tracking how many times autovac w
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> > We need more regression tests for handling the given format name. For
> > example,
> >
> > - more various input patterns.
> > - a function with the specified format name exists but it returns an
> > unexpected Node.
> > - looking for a han
On 01/04/2025 18:08, Andres Freund wrote:
Hi,
On 2025-04-01 13:34:53 +0300, Heikki Linnakangas wrote:
Here's a rebase of these patches.
Thanks!
Curious what made you do this? Do you need any parts of this soon?
No, I was just browsing through the commitfest.
I went ahead and committed th
Hi,
On 2025-04-02 18:58:11 +0200, Matthias van de Meent wrote:
> And here it is, v6 of the patchset, rebased up to master @ 764d501d.
Thanks!
Does anybody have an opinion about how non-invasive to be in the
back-branches? The minimal version is something like this diff:
diff --git i/src/backend
On Wed, Mar 19, 2025 at 12:44:38PM -0400, Andres Freund wrote:
> On 2025-03-19 12:28:33 -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>> > I'm currently planning to commit this sometime early-ish next week. One
>> > notable loose end is the lack of a pg_upgrade test with a non-default
>> > tab
On Thu, Mar 27, 2025 at 10:12 AM Andres Freund wrote:
> FWIW, I think we should just drop the HINT. We really have no clue what caused
> it and a HINT should imo have at least some value other than "*Shrug*", which
> is imo pretty much what these HINTs amount to, if they were a bit more blunt.
I
hi.
rebase, and some minor code comments change.
From 0af096b3959cc6f146bbe8a54a018c0e69beff2e Mon Sep 17 00:00:00 2001
From: jian he
Date: Mon, 24 Mar 2025 11:22:54 +0800
Subject: [PATCH v6 1/1] not null for virtual generated column
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Conte
On Mon, Mar 24, 2025 at 9:59 AM Richard Guo wrote:
> On Mon, Mar 24, 2025 at 9:54 AM Michael Paquier wrote:
> > On Mon, Mar 24, 2025 at 09:50:36AM +0900, Richard Guo wrote:
> > > Nice catch. The fix looks good to me. It seems to me that it's fine
> > > to go without a test case, since the fix i
Hi hackers,
The hashed IN optimization is only applied to the first encountered
ScalarArrayOpExpr during the expression tree traversal in
convert_saop_to_hashed_saop_walker(). Reason being that the walker
returns true which aborts the traversal.
This can be exhibited by running a query with
Hi,
On Wed, 19 Mar 2025 at 01:02, Aidar Imamov wrote:
>
> Hi!
>
> This is my first time trying out as a patch reviewer, and I don't claim
> to be
> an expert. I am very interested in the topic of buffer cache and would
> like to
> learn more about it.
Thank you so much for the review!
> pg_buff
On 2025-Mar-25, Tom Lane wrote:
> Christoph Berg writes:
> > For 2), Tom said that configurability is 1) often much less useful
> > than originally planned, and 2) tools have to cope with both settings
> > anyway, making implementing them harder. Plus, switching at run-time
> > makes the result e
On Thu, 3 Apr 2025 at 04:21, Andres Freund wrote:
> I was mildly
> surprised to see how expensive the new compact attribute checks are.
Is this a fairly deform-heavy workload? FWIW, before adding that
Assert, I did test to see if there was any measurable impact on the
time it took to run all the
On Fri, Mar 21, 2025 at 12:50 PM Nisha Moond wrote:
> Thanks, Hou-san, for the review and fix patches. I’ve incorporated
> your suggestions.
> Attached are the v7 patches, including patch 002, which implements
> stats collection for 'multiple_unique_conflicts' in
> pg_stat_subscription_stats.
On Tue, Mar 11, 2025 at 06:23:15PM -0700, Noah Misch wrote:
> On Wed, Mar 12, 2025 at 09:46:27AM +0900, Michael Paquier wrote:
> > On Tue, Mar 11, 2025 at 01:57:49PM -0700, Noah Misch wrote:
> > > Thanks for crafting back-branch versions. I've queued a task to confirm
> > > I get
> > > the same r
Hi,
On 2025-04-01 17:47:51 -0400, Andres Freund wrote:
> There are three different types of failures in the test_aio test so far:
And a fourth, visible after I enabled liburing support for skink.
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=skink&dt=2025-04-03%2007%3A06%3A19&stg
On 2025-Mar-20, jian he wrote:
> ATRewriteTable:
> for (i = 0; i < newTupDesc->natts; i++)
> {
> Form_pg_attribute attr = TupleDescAttr(newTupDesc, i);
> if (attr->attnotnull && !attr->attisdropped)
> {
> if (attr->attgenerated !=
On Thu, Apr 3, 2025 at 11:04 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Bertrand, Amit,
>
> > > I do prefer v5-PG17-2 as it is "closer" to HEAD. That said, I think that
> > > we should
> > > keep the slots active and only avoid doing the checks for them (they are
> > invalidated
> > > that's fine
On Fri, Mar 21, 2025 at 10:21 AM Tom Lane wrote:
> Robert Haas writes:
> > However, I'm a bit concerned about the overall premise of the patch
> > set. It feels like it is moving something that really ought to happen
> > at optimization time back to parse time. I have a feeling that's going
> >
Greetings, everyone!
When you try to run installcheck using a cluster that was initialized
with ICU (./initdb -D ../data --locale-provider=icu
--icu-locale='en_US_POSIX') and NO_LOCALE=1 you get a warning:
# +++ regress install-check in src/test/regress +++
# using postmaster
On Thu, Mar 20, 2025 at 5:23 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thu, Mar 20, 2025 at 3:06 PM Nisha Moond wrote:
> >
> > Attached is v6 patch with above comments addressed.
>
> Thanks updating the patch. I have some comments:
>
> 1.
>
> The naming style of variables changed in this function seem
On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
On Thu, Mar 20, 2025 at 4:53 PM Ashutosh Bapat
wrote:
>
> On Thu, Mar 20, 2025 at 10:25 AM Shubham Khanna
> wrote:
>
>
> +# run pg_createsubscriber with '--database' and '--all' without '--dry-run'
> +# and verify the failure
> +command_fails_like(
> + [
> + 'pg_createsubscriber',
> + '--verbose'
On Fri, 4 Apr 2025 at 01:17, Andrew Dunstan wrote:
>
>
> On 2025-04-01 Tu 1:59 AM, Mahendra Singh Thalor wrote:
> > On Mon, 31 Mar 2025 at 23:43, Álvaro Herrera
> > wrote:
> >> Hi
> >>
> >> FWIW I don't think the on_exit_nicely business is in final shape just
> >> yet. We're doing something sup
Hi,
Thank you for looking into this!
On Sat, 29 Mar 2025 at 23:10, Melanie Plageman
wrote:
>
> On Fri, Nov 29, 2024 at 6:20 AM Nazir Bilal Yavuz wrote:
> >
> > v4 is attached.
>
> I've started looking at this version. What I don't like about this
> structure is that we are forced to increment t
> On Thu, Mar 20, 2025 at 04:55:47PM GMT, Ni Ku wrote:
>
> I ran some simple tests (outside of PG) on linux kernel v6.1, which has
> this commit that added some hugepage support to mremap (
> https://patchwork.kernel.org/project/linux-mm/patch/20211013195825.3058275-1-almasrym...@google.com/
> ).
>
On Tue, 1 Apr 2025 at 15:49, Kirill Reshke wrote:
>
> On Tue, 1 Apr 2025, 11:45 vignesh C, wrote:
>>
>>
>> One thing I noticed was that if the materialized view is not refreshed
>> user will get stale data
>>
>> Should we document this?
>
> Does this patch alter thus behaviour? User will get stal
On Saturday, March 29, 2025, Kirill Reshke wrote:
> On Sat, 29 Mar 2025 at 09:47, jian he wrote:
> >
> > will use {table_beginscan, table_scan_getnextslot, table_endscan}
> > to output the data.
> > but views don't have storage, table_beginscan mechanism won't work.
> >
> > so i don't think this
On Fri, Mar 28, 2025 at 12:01 PM Ashutosh Bapat
wrote:
>
> Comparing root->join_rel_hash with EC->ec_derives_hash in the context
> of initial hash table size is a thinko on my part. It's less likely
> that there will be 1000 subqueries (requiring 1000 PlannerInfos) each
> with more than 32 join re
On Mon, 31 Mar 2025 at 19:27, Andrew Dunstan wrote:
>
>
> On 2025-03-31 Mo 5:34 AM, Mahendra Singh Thalor wrote:
> >
> > >
> > > There are a couple of rough edges, though.
> > >
> > > First, I see this:
> > >
> > >
> > > andrew@ub22arm:inst $ bin/pg_restore -C -d postgres
> > > --exclude-database=
Hi,
About a year ago, I attempted to start a mentoring program for code
contributors. In the end, 34 people applied, 21 of whom had some
on-list presence on pgsql-hackers, 10 committers agreed to mentor a
total of 15 applicants. Now, it's time once again to open
applications. Of the 15 mentor-ment
> True, although thinking about it more, they're not being sent to the
> same place. auto_explain goes to the log, and this goes to a view.
> What about something like this:
> progressive_explain = on | off
> progressive_explain_inteval = 5s
> If progressive_explain is off, then we don't populate t
On Fri, 4 Apr 2025 at 13:52, Mahendra Singh Thalor wrote:
>
> On Fri, 4 Apr 2025 at 01:17, Andrew Dunstan wrote:
> >
> >
> > On 2025-04-01 Tu 1:59 AM, Mahendra Singh Thalor wrote:
> > > On Mon, 31 Mar 2025 at 23:43, Álvaro Herrera
> > > wrote:
> > >> Hi
> > >>
> > >> FWIW I don't think the on_e
On Thu, Mar 27, 2025 at 10:31 PM Masahiko Sawada wrote:
>
> On Wed, Mar 26, 2025 at 12:32 PM Andrei Borodin wrote:
> >
> >
> >
> > 26.03.2025, 21:06, "Masahiko Sawada" :
> >
> > Agreed. I've done this in the attached patch.
> >
> > Great! The patch looks good to me.
>
> Thank you for reviewing it
On Wed Apr 2, 2025 at 6:58 PM PDT, Sami Imseih wrote:
>> > + indexes. If performance degrades after making an index invisible, it can
>> > be easily
>> > + be made visible using VISIBLE. Before making an index
>> > invisible, it's recommended
>> > + to check
>> > pg_stat_user_indexes.idx_scan
>>
On Sun, Mar 23, 2025 at 11:57:48AM -0400, Andres Freund wrote:
> On 2025-03-22 19:09:55 -0700, Noah Misch wrote:
> > On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote:
> > > Attached v2.11
> >
> > > Subject: [PATCH v2.11 05/27] aio: Add io_method=io_uring
> > > --- a/src/backend/utils/
On Tue, Mar 18, 2025 at 9:09 PM Thomas Munro wrote:
> All pushed (wasn't sure if Daniel was going to but once I got tangled
> up in all that kqueue stuff he probably quite reasonably assumed that
> I would :-)).
Attached are two more followups, separate from the libcurl split:
- 0001 is a patch o
On Thu, Apr 3, 2025 at 1:38 PM Masahiko Sawada wrote:
>
> On Wed, Apr 2, 2025 at 7:58 PM Amit Kapila
> wrote:
> >
> > On Thu, Apr 3, 2025 at 7:50 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Thu, Apr 3, 2025 at 3:30 AM Masahiko Sawada wrote:
> > >
> > > >
> > > > On Wed, Apr 2, 2025 at 6:3
Hi David,
On Fri, Mar 28, 2025 at 8:32 AM David Rowley wrote:
>
> Performing lookups on an appropriately sized hash table is going to
> perform better than lookups on a sparse table. The reason for this is
> that hash table probes rarely ever have a predictable memory access
> pattern, and the la
hi.
in src/bin/pg_dump/pg_dump.c
within function dumpTableSchema:
there are two occurrences of:
print_notnull = (tbinfo->notnull_constrs[j] != NULL &&
(tbinfo->notnull_islocal[j] ||
dopt->binary_upgrade
On Fri, 14 Mar 2025 at 23:10, Yuya Watari wrote:
> I have refactored the patches based on your feedback and attached the
> updated versions (v34). Additionally, I have included a diff between
> v33 and v34 for your quick reference.
Thanks for updating the patch. I've looked at v34-0001. Here are
Hi,
> ... and it is claimed that autovacuum will never be triggered in order
> to set hint bits, assuming we never modify the table again.
Actually I waited a bit and got a better EXPLAIN:
```
Index Only Scan using humidity_idx on humidity (cost=0.42..181.36
rows=1970 width=4) (actual time=0.3
On Sun, 30 Mar 2025 at 22:20, Andrew Dunstan wrote:
>
>
> On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
> > On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan
wrote:
> >>
> >> On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
> >>> On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
> On
On Mon, Mar 24, 2025 at 11:43:47AM -0400, Andres Freund wrote:
> On 2025-03-23 17:29:39 -0700, Noah Misch wrote:
> > commit 247ce06b wrote:
> > > + pgaio_io_reopen(ioh);
> > > +
> > > + /*
> > > + * To be able to exercise the reopen-fails path, allow
On Wed, Apr 02, 2025 at 12:13:52PM +, Hayato Kuroda (Fujitsu) wrote:
> Dear Amit, Bertrand,
>
> > The other idea to simplify the changes for backbranches:
> > sub reactive_slots_change_hfs_and_wait_for_xmins
> > {
> > ...
> > + my ($slot_prefix, $hsf, $invalidated, $needs_active_slot) = @_;
>
Alexander Korotkov 于2025年3月25日周二 18:57写道：
> On Fri, Nov 29, 2024 at 3:39 AM Tender Wang wrote:
> > Alexander Pyhalov 于2024年11月29日周五 00:02写道：
> >>
> >> Tender Wang писал(а) 2024-10-09 10:26:
> >> > Hi,
> >> >When I debug FDW join pushdown codes, I found below codes in
> >> > semijoin_target_
Tom Lane писал(а) 2025-03-26 22:38:
Vladlen Popolitov writes:
d) Above query will start parallel worker(s). When worker(s)
finish(es),
it/they send SIGUSR1 that is caught by debugger. When you dimiss
the signal message, you find that query continues to run, but really
it
waits (in latch.c or
On Mon, Mar 31, 2025 at 3:46 PM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > tzdata 2025b has been released on 3/22[1]. Do we need to update the
> > tzdata.zi file on HEAD and backbranches?
>
> Yup, eventually, but I don't normally worry about it until we are
> approaching a release date. tzd
Hello,
If you're already aware of this and have taken it into account, please
feel free to ignore this.
As described in the recent commit a0ed19e0a9e, many %ll? format
specifiers are being replaced with %.
I hadn’t paid much attention to this before, but I happened to check
how this behaves on W
Hi,
On 2025-03-20 17:08:54 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 20, 2025 at 01:33:26PM -0700, Jacob Champion wrote:
> >> So one question for the collective is -- putting Curl itself aside --
> >> is having a basic-but-usable OAuth flow, out of the box, worth the
> >> cos
On Tue, Mar 18, 2025 at 12:07 PM David G. Johnston
wrote:
>
> On Monday, March 17, 2025, Shubham Khanna wrote:
>>
>>
>> I have added validation for "all" to address both issues at once.
>>
>
> Usage needs to be changed to refer to object types and we should try and
> specify which are valid ther
Robert Haas writes:
> On Tue, Mar 18, 2025 at 10:31 AM Andrew Dunstan wrote:
>> Just a question if everyone wants to run this. Koel takes about 10s to run
>> the indent test.
> Well, IMHO, that's pretty cheap insurance against having to push a
> second commit to fix indentation. But I guess one
On Sat, 1 Mar 2025 at 04:35, Jeff Davis wrote:
>
> On Mon, 2024-12-16 at 20:05 -0800, Jeff Davis wrote:
> > On Wed, 2024-10-30 at 08:08 -0700, Jeff Davis wrote:
> >
>
> Rebased v14.
>
> The approach has changed multiple times. It starte off with more in-
> core code, but in response to review feed
> > 2/
> > It should be noted that the plan will not print to the log until
> > the plan begins executing the next plan node? depending on the
> > operation, that could take some time ( i.e.long seq scan of a table,
> > etc.)
> > Does this behavior need to be called out in docs?
>
> Seems reasonabl
>
> * Changed to use LookupExplicitNamespace()
>
Seems good.
> * Added test for temp tables
>
+1
> * Doc fixes
So this patch swings the pendulum a bit back towards accepting some things
as errors. That's understandable, as we're never going to have a situation
where we can guarantee that th
1 - 100 of 239 matches
Mail list logo
