Hi,
On Mon, Dec 30, 2024 at 07:12:54PM +0900, Michael Paquier wrote:
> On Mon, Dec 30, 2024 at 09:44:45AM +, Bertrand Drouvot wrote:
> > I think that replicating stats that are used by autovacuum would be an
> > additional
> > benefit, so +1 for the idea number 2). This is an "issue" that has
Hi Sami
Many people have encountered situations where autovacuum or auto analyze on
tables are not triggered in time, leading to suboptimal execution plans and
some performance issues. When analyzing such problems, we often need to
trace back to when autovacuum or auto analyze was triggered for
On Fri, Dec 27, 2024 at 9:22 AM vignesh C wrote:
>
>
> Few comments:
> 1) We have disabled the similar configuration max_slot_wal_keep_size
> by setting to -1, as this GUC also is in similar lines, should we
> disable this and let the user configure it?
> +/*
> + * Invalidate replication slots tha
On Mon, Dec 30, 2024 at 11:05 AM Peter Smith wrote:
>
> On Tue, Dec 24, 2024 at 10:37 PM 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 commen
hi.
[48/208] Compiling C object
contrib/postgres_fdw/postgres_fdw.so.p/postgres_fdw.c.o
FAILED: contrib/postgres_fdw/postgres_fdw.so.p/postgres_fdw.c.o
/usr/local/gcc-14.1.0/bin/gcc-14.1.0
-Icontrib/postgres_fdw/postgres_fdw.so.p -Isrc/include
-I../../Desktop/pg_src/src5/postgres/src/include
-Isrc
On Tue, Dec 31, 2024 at 4:29 AM Peter Smith wrote:
>
> Hi Shubham.
>
> Here are some review comments for the patch v3-0001.
>
> ==
> Commit message.
>
> 1.
> I can't pinpoint anything specifically wrong about this commit
> message, but it seems to be repeating the same information over and
> o
Hi all,
Logical decoding (and logical replication) are available only when
wal_level = logical. As the documentation says[1], Using the 'logical'
level increases the WAL volume which could negatively affect the
performance. For that reason, users might want to start with using
'replica', but when
The last_(auto)vacuum is useful because it allows
the user to monitor vacuum to ensure that vacuums
are completing on a relation at expected intervals.
I am not sure what value a start time will provide.
Can you provide a reason for this?
Regards,
Sami Imseih
> Should this not behave like if you drop (or create) an index
> during a prepared statement? I have not yet looked closely at
> this code to see what could be done.
>
> Regards,
I looked at this a bit more and ATExecEnableDisableIndex
needs some tweaks.
What should be getting invalidated in the
On Mon, Dec 30, 2024 at 09:00:59PM -0500, Tom Lane wrote:
>
> This ties into a criticism I have of the criteria that outfits like
> Debian and Red Hat seem to have for back-patching bug fixes: if it's
> labeled "CVE" then it must get fixed, even for something as narrow
> and low-impact as CVE-2024
On Mon, Dec 30, 2024 at 10:02:18PM -0500, Roberto C. Sánchez wrote:
> Do you mean that branches for releases which are EOL are not looked at?
> I understand that completely. What I was hoping for here was that
> someone who was familiar with the old code might be able to look at my
> analysis and e
On Tue, Dec 31, 2024 at 10:23:29AM +0900, Michael Paquier wrote:
> On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> > I saw your question and was kind of stumped about how to answer. We
> > rarely look at back branches for backpatch analysis, so I think we are
> > kind of confused
Hi Bruce,
On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> On Mon, Dec 30, 2024 at 04:50:12PM -0500, Roberto C. Sánchez wrote:
> > On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> > > Greetings pgsql devs,
> > >
> > > I would appreciate a review of my strategy
Michael Paquier writes:
> On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
>> Is our five-year insufficient?
> FWIW, I'm already on the side that five-year support is quite good and
> I'd side with not extending that, even argue about reducing it
> (anti-tomato armor is now on). Ba
On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> I saw your question and was kind of stumped about how to answer. We
> rarely look at back branches for backpatch analysis, so I think we are
> kind of confused on how to answer. Under what circumstances are you
> supported versions
On Mon, Dec 30, 2024 at 3:12 PM David Rowley wrote:
>
> On Sat, 28 Dec 2024 at 08:14, James Hunter wrote:
> > 2. We use this backend_work_mem to "adjust" work_mem values used by
> > the executor. (I don't care about the optimizer right now -- optimizer
> > just does its best to predict what will
On Sat, Dec 28, 2024 at 02:25:16AM +0100, Tomas Vondra wrote:
> And the more I think about it the more I'm convinced we don't need to
> keep the data about past runs in memory, a file should be enough (except
> maybe for a small buffer). That would mean we don't need to worry about
> dynamic shared
On Sat, Dec 28, 2024 at 11:24 PM Jim Nasby wrote:
>
> IMHO none of this will be very sane until we actually have cluster-level
> limits. One sudden burst in active connections and you still OOM the instance.
Fwiw, PG does support "max_connections" GUC, so a backend/connection -
level limit, time
On Sat, Dec 28, 2024 at 10:26 AM Jeremy Schneider
wrote:
>
Thanks for the feedback, Jeremy!
> While I don't have a detailed design in mind, I'd like to add a strong
> +1 on the general idea that work_mem is hard to effectively use because
> queries can vary so widely in how many nodes might need
On Fri, Dec 27, 2024 at 12:32:25PM +0900, Michael Paquier wrote:
> For clarity, the patch set has been split into several pieces, I hope
> rather edible:
> - 0001, a fix I've posted on a different thread [1], used in patch
> 0004 to test this new facility.
> - 0002, a refactoring piece to be able t
On Sat, Dec 28, 2024 at 6:57 AM Tomas Vondra wrote:
>
> On 12/28/24 13:36, Anton A. Melnikov wrote:
> >
> > ... In more details let me suggest
> > the following steps or parts:
> > 1) realize memory limitation for a separate backend independent from the
> > work_mem GUC;
> > 2) add workmem-like li
On Mon, Dec 30, 2024 at 12:00:26PM +0100, Daniel Gustafsson wrote:
> On 30 Dec 2024, at 02:24, Michael Paquier wrote:
>> Not something I'm planning to care about, just noting that from the
>> top of OpenSSL master branch (0958f5a5bc47 as of today):
>> $ git grep eay32
>> .gitignore:/ms/libeay32.de
On Mon, Dec 30, 2024 at 2:56 PM David Rowley wrote:
>
> On Tue, 31 Dec 2024 at 10:11, James Hunter wrote:
> > Does PostgreSQL currently rescan Hash Joins when they are "no longer
> > needed," to free work_mem early? If so, then I would try to reuse this
> > existing logic to decide which nodes ne
On Sat, 28 Dec 2024 at 08:14, James Hunter wrote:
> 2. We use this backend_work_mem to "adjust" work_mem values used by
> the executor. (I don't care about the optimizer right now -- optimizer
> just does its best to predict what will happen at runtime.)
While I do want to see improvements in thi
On Mon Dec 30, 2024 at 5:39 PM CET, Tom Lane wrote:
Bruce Momjian writes:
I certainly would love to see storage I/O numbers as distinct from
kernel read I/O numbers.
Me too, but I think it is 100% wishful thinking to imagine that
page fault counts match up with that.
Okay I played around
Hi Shubham.
Here are some review comments for the patch v3-0001.
==
Commit message.
1.
I can't pinpoint anything specifically wrong about this commit
message, but it seems to be repeating the same information over and
over.
==
Missing pg_createsubscriber documentation?
2.
I thought any
On Tue, 31 Dec 2024 at 10:11, James Hunter wrote:
> Does PostgreSQL currently rescan Hash Joins when they are "no longer
> needed," to free work_mem early? If so, then I would try to reuse this
> existing logic to decide which nodes need work_mem concurrently.
>
> If not, then all nodes that use w
On Mon, Dec 30, 2024 at 04:50:12PM -0500, Roberto C. Sánchez wrote:
> On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> > Greetings pgsql devs,
> >
> > I would appreciate a review of my strategy for backporting the commits
> > related to CVE-2024-10978. (I am working with versi
On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> Greetings pgsql devs,
>
> I would appreciate a review of my strategy for backporting the commits
> related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
> for some older Debian releases.)
>
> My conclusion is
On Dec 25, 2024, at 11:25 AM, Tomas Vondra wrote:
> But maybe it'd be possible to just write the entries to a file. We don't
> need random access to past entries (unlike e.g. pg_stat_statements), and
> people won't query that very often either.
Assuming this doesn’t add significant complexity I t
On Thu, Dec 26, 2024 at 1:37 AM vignesh C wrote:
>
> Hi,
>
> Currently, we restart the table synchronization worker after the
> duration specified by wal_retrieve_retry_interval following the last
> failure. While this behavior is documented for apply workers, it is
> not mentioned for table synch
On Fri, Dec 27, 2024 at 5:48 PM Tomas Vondra wrote:
> Whenever I've been thinking about this in the past, it wasn't clear to
> me how would we know when to start adjusting work_mem, because we don't
> know which nodes will actually use work_mem concurrently.
You certainly know the PostgreSQL sou
Yugo NAGATA writes:
> On Wed, 20 Nov 2024 12:43:16 -0500
> Tom Lane wrote:
>> ... It seems to me that we should
>> think about this, for MVs as well as those other object types,
>> as fundamentally a dependency problem. That is, the reason
>> we can't allow a reference to an ENR in a long-lived
Hello!
One more thing (maybe I missed it in the patch, but anyway) - should we
add some migration to ensure what old databases will get enabled=true by
default after upgrade?
Best regards,
Mikhail.
On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
> On Thu, 2024-12-26 at 13:54 -0500, Bruce Momjian wrote:
> > I am _again_ not happy with this part of the patch. Please reply to
> > the
> > criticism in my November 19th email:
> >
> >
> > https://www.postgresql.org/message-id
On Tue, 31 Dec 2024 at 06:24, Ayush Vatsa wrote:
> To me, using a range of pages to prewarm a relation doesn’t seem like a
> common use case. For example, if a user calls prewarm(100, 200),
> how would they decide those specific numbers? While it’s possible to
> inspect the contents of those pages
On Thu, 2024-12-26 at 13:54 -0500, Bruce Momjian wrote:
> I am _again_ not happy with this part of the patch. Please reply to
> the
> criticism in my November 19th email:
>
>
> https://www.postgresql.org/message-id/zz0t1benifdnx...@momjian.us
>
> rather than ignoring it and posting the
> Rebased with the latest master as well.
Hi,
This is a great, long needed feature. Thanks for doing this.
I am late to this thread, but I took a look at the current patch
and have some comments as I continue to look.
1/
instead of
+ If true, the index is currently enabled and should be
On Mon, Dec 30, 2024 at 4:03 PM vignesh C wrote:
>
> On Mon, 30 Dec 2024 at 12:04, Shubham Khanna
> wrote:
> >
> > On Mon, Dec 30, 2024 at 10:10 AM vignesh C wrote:
> > >
> > > On Mon, 30 Dec 2024 at 09:34, Shubham Khanna
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Currently, there is a ri
Japin Li writes:
> When I read the PL/pgSQL source code, I found that plpgsql_yyparse() is
> defined
> in pl_gram.y, however, the comment says it is defined in gram.y.
Yeah, apparently missed when we renamed that file years ago.
Pushed, thanks for spotting this!
regards,
> I wrote:
> > Sami Imseih writes:
> >> I am attaching a patch that deals with the RTE_JOIN case.
>
> > I'll take a look. Thanks for the test demonstrating that
> > this makes a visible performance difference.
>
> Pushed with some simplification: we don't need a new flag,
> because none of the ca
> This proposal introduces a feature to print execution plans of active
> queries in an in-memory shared hash object so that other sessions can
> visualize them with a new view: pg_stat_progress_explain.
Thanks for this thread and for sharing the presentation
material. +1 for the idea of adding in
On Mon, Dec 30, 2024 at 10:54:21PM +0530, Ayush Vatsa wrote:
> When I initially read the documentation, I found it unclear how someone
> would practically use the range feature. For instance, how would a user
> determine the specific range of pages they need in the buffer cache?
> Since PostgreSQL
On Mon, Dec 30, 2024 at 11:08 AM Michail Nikolaev <
michail.nikol...@gmail.com> wrote:
> Hello.
>
> A few comments on patch:
>
Thank you for the feedback.
>
> > + temporarily reducing the overhead of index maintenance
> > + during bulk data loading operations
>
>>
>
But tuples are still ins
> hmm, do we really need to highlight one specific usage for the range
> like this? I think mentioning this could just confuse readers as it
> makes it sound like using a range is going to magically run something
> in parallel.
I believe highlighting that particular use case would indeed be helpfu
On Mon, 30 Dec 2024 at 10:12, Michael Paquier wrote:
>
> On Fri, Dec 27, 2024 at 08:13:53AM +, Zhijie Hou (Fujitsu) wrote:
> > Thanks for updating patches ! They look good to me.
>
> Fine by me as well. I had a bit of time today, so I've taken care of
> all this one down to 15 for now after c
Bruce Momjian writes:
> On Fri, Dec 27, 2024 at 03:15:40PM +0100, Jelte Fennema-Nio wrote:
>> On Tue Dec 24, 2024 at 4:52 PM CET, Tom Lane wrote:
>>> torikoshia writes:
I have attached a PoC patch that modifies EXPLAIN to include page
fault information during both the planning and execu
On Sun, Dec 29, 2024 at 8:19 PM Rafael Thofehrn Castro
wrote:
> Plans are only printed if the new GUC parameter progressive_explain is
> enabled.
>
Maybe track_explain instead? In the spirit of track_activity.
- progressive_explain_output_size: max output size of the plan printed in
> the in-me
"Jelte Fennema-Nio" writes:
> The current situation seems utterly messed up though. One thing that
> shocks me is that we're, by default and without warning, parsing IST as
> Israel Standard Time instead of the timezone that 17% of the world's
> population uses: Indian Standard Time. And even with
On Fri, Dec 27, 2024 at 03:15:40PM +0100, Jelte Fennema-Nio wrote:
> On Tue Dec 24, 2024 at 4:52 PM CET, 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
> > > q
Hello.
A few comments on patch:
> + temporarily reducing the overhead of index maintenance
> + during bulk data loading operations
>
But tuples are still inserted, where the difference come from?
> or verifying an index is not being used
> + before dropping it
Hm, it does not provide
I like this, very useful. It's a shame about the conflict with \dx (lesson
for the future: think extra carefully about option namings!). I am
impressed that \dx \d \d+ \d+x and even \dxx all work as one might
intuit with this patch.
Cheers,
Greg
I missed one more point earlier.
I don't think "failure" is a good name for the setting as it's
a bit too harsh. What we really have is a "shortage" of
workers.
Instead of
+{"failure", LOG_PARALLEL_WORKERS_FAILURE, false},
what about?
{"shortage", LOG_PARALLEL_WORKERS_SHORTAGE, false},
Re
Hi,
Thank you for working on this!
On Tue, 10 Dec 2024 at 00:15, Darek Ślusarczyk wrote:
>
> I've prepared another patch:
> - it prioritizes libssl and libcrypto over ssleay32 and libeay32
> - it checks ssleay32 and libeay32 on windows only
> - I tested it locally on both lnx/win enforcing vario
On 29.10.24 09:47, Peter Eisentraut wrote:
I kind of wonder if we really want to do this. It adds no
functionality, and it forecloses the possibility of changing
the definition later. I understand and agree with your conclusion
that it's pretty much impossible to do what the SQL standard sugges
On Sun Dec 29, 2024 at 11:56 PM CET, Tom Lane wrote:
Hmm, I don't like your phrasing using "IANA time zone database",
because that makes it sound like we'll take any abbreviation that's
found anywhere in that whole data set. What the proposal actually
does is to recognize any abbreviation that i
On Sun Dec 29, 2024 at 11:49 PM CET, Jelte Fennema-Nio wrote:
Maybe changing the default value of timezone_abbreviations is a better
solution to the problem, or in addition to the proposed patch.
To clarify, I meant maybe changing the default of timezone_abbreviations
to be empty. It sounds lik
> On 30 Dec 2024, at 02:24, Michael Paquier wrote:
>
> On Fri, Dec 27, 2024 at 03:09:48PM +0100, Daniel Gustafsson wrote:
>> The thread in [0] which adds Meson support for *eay32 OpenSSL library names
>> on
>> Windows reminded me that we should remove these from master since we no
>> longer
>>
On Mon, 30 Dec 2024 at 12:04, Shubham Khanna
wrote:
>
> On Mon, Dec 30, 2024 at 10:10 AM vignesh C wrote:
> >
> > On Mon, 30 Dec 2024 at 09:34, Shubham Khanna
> > wrote:
> > >
> > > Hi,
> > >
> > > Currently, there is a risk that pg_createsubscriber may fail to
> > > complete successfully when t
On Mon, Dec 30, 2024 at 09:44:45AM +, Bertrand Drouvot wrote:
> I think that replicating stats that are used by autovacuum would be an
> additional
> benefit, so +1 for the idea number 2). This is an "issue" that has been raised
> multiple times (like in [1]).
>
> [1]:
> https://www.postgre
On Mon, Dec 30, 2024 at 08:34:54AM +, Bertrand Drouvot wrote:
> On Fri, Dec 27, 2024 at 09:23:12AM +0900, Michael Paquier wrote:
>> All that is addressed in the patch attached. Feel free if you have
>> any comments.
>
> The patch is pretty straightforward and LGTM.
Thanks for double-checking
Hi,
On Wed, Dec 25, 2024 at 10:10:44AM +0900, Michael Paquier wrote:
>
> 2) The main issue I am trying to tackle is autovacuum giving up on
> tables if there are no stats entries, so we could add *some* WAL
> logging of the relation stats that are relevant for autovacuum, then
> replay them. I t
Hi,
On December 30, 2024 10:29:53 AM GMT+01:00, Peter Eisentraut
wrote:
>On 25.12.24 11:22, Heikki Linnakangas wrote:
>> Thanks for the links. It's disappointing there isn't a standard way to do
>> this. It's nice to see the comments in cpython's makeexp_aix script
>> explaining the "hidden tr
On 25.12.24 11:22, Heikki Linnakangas wrote:
Thanks for the links. It's disappointing there isn't a standard way to
do this. It's nice to see the comments in cpython's makeexp_aix script
explaining the "hidden tricks". I'd love to see similar comments in
mkldexport.sh explaining what it does. A
rebase.
v5 also attached removes the libxml2 dependency of unescape_xml().
Background: the existing function escape_xml() intentionally avoids
libxml2 dependency and the previously used libxml2 functions
xmlStringDecodeEntities() and xmlDecodeEntities() got deprecated.
--
Jim
From f38c714220be8
The output from various psql meta-commands such as \df+ can be quite
wide, making it hard to read, and there is another patch [1] that will
make it even wider. The output is much more readable if expanded mode
is used, but it's somewhat inconvenient to keep turning that on and
off, if you don't wan
Hi, hackers
When I read the PL/pgSQL source code, I found that plpgsql_yyparse() is defined
in pl_gram.y, however, the comment says it is defined in gram.y.
PFA.
--
Regrads,
Japin Li
>From 9629535310eef217f195fc3526d8227b9f6ab29c Mon Sep 17 00:00:00 2001
From: Japin Li
Date: Mon, 30 Dec 2024
Hi,
On Fri, Dec 27, 2024 at 09:23:12AM +0900, Michael Paquier wrote:
> 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 s
Hi! Thank you for your interest to this subject!
On 27.12.2024 15:53, Ilia Evdokimov wrote:
Hi Alena,
Thank you for your work on subqueries with JOIN.
Have you considered the scenario where in subquery includes a qual
like (tc.aid = 1)? When I tried executing those queries I receive
differen
69 matches
Mail list logo
