On Thu, Dec 26, 2024 at 06:11:25PM +0300, Давыдов Виталий wrote:
> I concerned about twophase file name generation. The function
> TwoPhaseFilePath() is pretty straitforward and unambiguous in 16 and
> earlier versions. The logic of this function in 17+ seems to be more
> complex. I do not understa
On Wed, Dec 25, 2024 at 5:29 PM Michael Paquier wrote:
>
> On Mon, Dec 16, 2024 at 05:25:45PM +0800, jian he wrote:
> > i've split into 3 patches, feel free to merge them in any way.
> > v12-0001: add error position for ATPrepAlterColumnType.
>
> For this one, why don't you do the same for undefi
Kohei Harikae (Fujitsu) писал(а) 2024-12-27 04:31:
Hi,
Thank you for your advice.
I added a sample setting PKG_CONFIG_PATH based on your advice.
How do you think about this?
Regards,
Kohei Harikae
Hi,
From my point of view it looks good. Actual information is added,
excessive information is
On Fri, Dec 27, 2024 at 11:30 AM vignesh C wrote:
> > > > >
> The documentation requires a minor update: instead of specifying
> subscriptions, the user will specify multiple databases, and the
> subscription will be created on the specified databases. Documentation
> should be updated accordingly
On Fri, 13 Dec 2024 at 15:33, Shubham Khanna
wrote:
>
> On Fri, Dec 13, 2024 at 2:39 PM vignesh C wrote:
> >
> > On Fri, 13 Dec 2024 at 13:01, Shubham Khanna
> > wrote:
> > >
> > > On Fri, Dec 13, 2024 at 12:20 PM Peter Smith
> > > wrote:
> > > >
> > > > Hi Shubham.
> > > >
> > > > Here are my
On Fri, Dec 27, 2024 at 8:34 AM Andrei Lepikhov wrote:
> On 12/24/24 10:42, Yurii Rashkovskii wrote:
> > On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov > I've reviewed the patch, and it is great that you support more flexible
> > versioning now. I am just wondering a bit about the case where `
On Tue, Dec 24, 2024 at 04:33:47PM +0900, Michael Paquier wrote:
> I am planning to get this one applied around the end of this week on
> Friday for HEAD, that should be enough if there are comments and/or
> objections.
And done for now. If there are any remarks and/or objections, of
course feel
On Wed, Dec 25, 2024 at 6:36 PM Richard Guo wrote:
> In v16 and later, the nullingrels within the expression "t2.a + t2.b"
> prevent it from being matched to the corresponding expression in
> extended statistics, forcing us to use DEFAULT_UNK_SEL(0.005).
Furthermore, even without extended statist
On Wed, 25 Dec 2024 at 13:55, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Marc,
>
> > Thanks again for this new patch.
> >
> > Unfortunately it does not compile (17.2 source):
>
> Right, because of the reason I posted [1].
>
> I updated the patch which did the same approach. It could pass my CI.
Let'
On Thu, Dec 26, 2024 at 06:58:11PM +0100, Tomas Vondra wrote:
> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> make a fundamental difference ...
>
> Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
> limit, or possibly removing it entirely (and a
On Tue, 24 Dec 2024 at 17:07, Nisha Moond wrote:
>
> On Fri, Dec 20, 2024 at 3:12 PM Amit Kapila wrote:
>>
>> On Mon, Dec 16, 2024 at 4:10 PM Nisha Moond wrote:
>> >
>> > Here is the v56 patch set with the above comments incorporated.
>> >
>>
>> Review comments:
>> ===
>> 1.
>> + {
>
Hi all,
While brainstorming on the contents of the thread I have posted a
couple of days ago, I have been looking at what could be done so as
pgstats and WAL-logging could work together. This was point 2) from
this message:
https://www.postgresql.org/message-id/z2tblemfuofzy...@paquier.xyz
While
Hi Tomas
> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> make a fundamental difference ...
agree
> Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
> limit, or possibly removing it entirely (and accepting anything the
> system can handle).
yes,
On Sat, Dec 7, 2024 at 11:24:37AM -0500, Tom Lane wrote:
> Jack Bay writes:
> > Would it be possible to add support for unsigned 64-bit and unsigned
> > 32-bit integers to postgresql?
>
> This has been discussed before, and we've concluded that the impact
> on the numeric promotion hierarchy (th
On 12/24/24 10:42, Yurii Rashkovskii wrote:
On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov I've reviewed the patch, and it is great that you support more flexible
versioning now. I am just wondering a bit about the case where `minfo-
>name` can be `NULL` but `minfo->version` isn't, or where b
Hi,
Thank you for your advice.
I added a sample setting PKG_CONFIG_PATH based on your advice.
How do you think about this?
Regards,
Kohei Harikae
-Original Message-
From: Vladlen Popolitov
Sent: Wednesday, December 25, 2024 7:28 PM
To: Harikae, Kohei/張替 浩平
Cc: 'Andres Freund' ; 'pgsq
On 12/27/24 01:26, David Wheeler wrote:
On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote:
Looking into the control file, I see that most parameters are
unnecessary for the library. Why do we have to maintain this file?
Well, either way you have to load the extension, either CREATE EXTEN
Michel Pelletier writes:
> On Mon, Dec 23, 2024 at 8:26 AM Tom Lane wrote:
>> 2. If the problem is primarily with passing the same object to
>> multiple parameters of a function, couldn't you detect and optimize
>> that within the function?
> Ah that's a great idea, and it works beautifully! No
Hi all,
While doing more stuff related to pgstats and WAL, I have bumped on
the fact that the module injection_points uses for its
variable-numbered stats a pending flush callback but it does not
handle its entries so as these would be handled locally first, with a
final flush timed by pgstat_repo
On Thu, Dec 26, 2024 at 06:07:45PM -0500, Bruce Momjian wrote:
> On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
>> I think removal is not happening. The documentation for attndims
>> already says
>>
>> Number of dimensions, if the column is an array type; otherwise
>> 0. (Prese
On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > So, if users are referencing attndims and the values are not accurate,
> > how useful are they? I was suggesting removal so people would stop
> > relying on inaccurate information, or we correct attndims to be
>
Bruce Momjian writes:
> So, if users are referencing attndims and the values are not accurate,
> how useful are they? I was suggesting removal so people would stop
> relying on inaccurate information, or we correct attndims to be
> accurate. Allowing people to continue relying on inaccurate info
On Thu, 26 Dec 2024 at 22:41, Ilia Evdokimov
wrote:
> I'm sharing a small patch that removes an unused parameter (totalrows)
> from compute_expr_stats function in extended_stats.c .
Thanks. It's a static function, so I agree that there's no need to
keep an unused parameter.
Pushed.
David
On Thu, 26 Dec 2024 13:15:59 +0900
torikoshia wrote:
> On 2024-12-25 00:52, Tom Lane wrote:
> > torikoshia writes:
> >> I have attached a PoC patch that modifies EXPLAIN to include page
> >> fault
> >> information during both the planning and execution phases of a
> >> query.
> >
> > Surel
On Mon, Dec 23, 2024 at 01:56:24PM +0900, Michael Paquier wrote:
> On Thu, Dec 12, 2024 at 03:40:32PM +0800, jian he wrote:
> > remove pg_type typndims column patch attached.
>
> FWIW, I have been paying more attention to applications that may use
> this attribute and bumped into quite a few cases
On Wed, Dec 11, 2024 at 10:49:53PM -0500, Corey Huinker wrote:
> From cf4e731db9ffaa4e89d7c5d14b32668529c8c89a Mon Sep 17 00:00:00 2001
> From: Corey Huinker
> Date: Fri, 8 Nov 2024 12:27:50 -0500
> Subject: [PATCH v34 11/11] Add --force-analyze to vacuumdb.
>
> The vacuumdb options of --analyze-
On Thu, Dec 19, 2024 at 09:23:20PM -0800, Jeff Davis wrote:
> On Fri, 2024-12-13 at 00:22 -0500, Corey Huinker wrote:
> > Per offline conversation with Jeff, adding a --no-schema to pg_dump
> > option both for completeness (we already have --no-data and --no-
> > statistics), but users who previous
On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote:
> Looking into the control file, I see that most parameters are
> unnecessary for the library. Why do we have to maintain this file?
Most of the parameters apply to SQL extensions.
> The 'CREATE EXTENSION' statement would have made sense
On 12/26/24 17:00, wenhui qiu wrote:
> Hi
>
> As far as I know, more than 10,000 tables of instances are often
> encountered,
> So I insist that the maximum can be appropriately increased to 256MB，
> Can be more adaptable to many table situations
>
If 128MB is insufficient, why would 256MB
On Fri, Dec 20, 2024 at 9:55 PM John Naylor wrote:
>
> On Sat, Dec 21, 2024 at 2:17 AM Masahiko Sawada wrote:
> >
> > On Fri, Dec 20, 2024 at 2:27 AM John Naylor wrote:
>
> > > v3-0001 allocates the iter data in the caller's context. It's a small
> > > patch, but still a core behavior change so
Hi
As far as I know, more than 10,000 tables of instances are often
encountered,
So I insist that the maximum can be appropriately increased to 256MB，Can be
more adaptable to many table situations
On Thu, 26 Dec 2024 at 23:23, Robert Treat wrote:
> On Wed, Dec 25, 2024 at 12:26 PM Tomas Vondr
On Wed, Dec 25, 2024 at 12:26 PM Tomas Vondra wrote:
>
> Hi,
>
> On 12/23/24 07:35, wenhui qiu wrote:
> > Hi Tomas
> > This is a great feature.
> > + /*
> > + * Define (or redefine) custom GUC variables.
> > + */
> > + DefineCustomIntVariable("stats_history.size",
> > + "Sets the amount of me
Hi Michael,
> Here are two patches to address both issues:
Thank you for the preparing the patches and test simplification. My bad, I
overcompilcated it.
I concerned about twophase file name generation. The function
TwoPhaseFilePath() is pretty straitforward and unambiguous in 16 and earlier
This is just a rebase.
As stated before, I added some information to the error message for
parallel queries as an experiment. It can be removed, if you re not
convinced.
---
Benoit Lobréau
Consultant
http://dalibo.comFrom 7e63f79226357f2fe84acedb950e64383e582b17 Mon Sep 17 00:00:00 2001
From:
>Hi,
>
>I provided a patch a month ago with a new approach as suggested by David.
>Unfortunately, it didn't get any attention in the November CF.
>
>I would appreciate your feedback on whether we should proceed with this new
>approach or stick with the previous one.
>
>Regards,
>Hunaid Sohail
--/
Hello, Hou!
> So, I think it's not a bug in the committed patch but an issue in the
testing
> venvironment. Besides, since we have not seen such failures on BF, I
think it
> may not be necessary to improve the testcases.
Thanks for your analysis!
Yes, probably WSL2/Windows interactions cause st
Hi Umar, hi Pavel,
Thanks for taking a look at this patch!
On 26.12.24 05:15, Umar Hayat wrote:
> Hi,
> +1 for the enhancement.
>
> I haven't compiled and reviewed the full patch yet, please see a few
> comments from my side based on static analysis.
>
> 1. Though changes are targeted for XMLNAME
On Thu, 12 Dec 2024 at 20:32, vignesh C wrote:
>
> On Wed, 11 Dec 2024 at 11:39, Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, December 11, 2024 12:28 PM vignesh C
> > wrote:
> > > Hi,
> > >
> > > I'm starting a new thread for one of the issues reported by Sawada-san at
> > > [1].
> > >
Hi,
On Tue, 24 Dec 2024 at 09:13, Michael Paquier wrote:
>
> On Fri, Dec 06, 2024 at 12:41:55PM +0300, Nazir Bilal Yavuz wrote:
> > Thanks! I think 'track' is a better word in this context. I used
> > 'tracked in ...', as it sounded more correct to me (I hope it is).
>
> Splitting op_bytes into t
Good day.
Commit "Fix corruption when relation truncation fails." [0] makes
smgrtruncate be called in a critical section. Unfortunately in version
13 it leads to occasional call to palloc0 inside of critical section,
which triggers Assert in debug builds:
- smgrtruncate calls mdtruncate
- md
Hi hackers,
I'm sharing a small patch that removes an unused parameter (totalrows)
from compute_expr_stats function in extended_stats.c .
This function originally appeared in commit
a4d75c86bf15220df22de0a92c819ecef9db3849, which introduced extended
statistics on expressions. From what I can
41 matches
Mail list logo
