On Fri, Jul 11, 2025 at 12:45 AM Thomas Munro
wrote:
> On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou wrote:
> > > I applied the patch on PostgreSQL v17 and am testing it now. I chose
> > > ftruncate method and I see ftruncate in action using strace while doing
> > > pg_restore of a big dat
Hi,
Thank you all for reporting the failure and sharing your inputs!
On Tue, 29 Jul 2025 at 09:07, Michael Paquier wrote:
>
> On Tue, Jul 29, 2025 at 12:41:39AM -0400, Tom Lane wrote:
> > Alexander Lakhin writes:
> > > The new check has failed on mamba [1], apparently because this animal is
> >
On 28.07.2025 15:49, Andrey Borodin wrote:
I also attach a version for PG17, maybe Dmitry could try to reproduce the
problem with this patch.
Andrey, thank you very much for your work, and also thanks to Álvaro for
joining the discussion on the problem. I ran tests on PG17 with patch
v8, the
Hi,
On Tue, 29 Jul 2025 at 04:46, Michael Paquier wrote:
>
> > - 0002 is the actual patch that improves error reporting in the
> > 027_stream_regress test by using the read_file_ends() function. It
> > adds a regression_log_helper() function, which reads the
> > PG_TEST_FILE_READ_LINES environmen
hi.
after run the v2 python script and ``git apply
v2-0001-update-filelist.sgml-allfiles.sgml.no-cfbot``
git status -u
shows:
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified
On Tue, Jul 29, 2025 at 12:41:39AM -0400, Tom Lane wrote:
> Alexander Lakhin writes:
> > The new check has failed on mamba [1], apparently because this animal is
> > too slow for pg_isready:
>
> There is something strange happening on mamba --- not sure what,
> but its cycle time for the past wee
On Mon, Jul 28, 2025 at 08:53:43PM -0700, Lukas Fittl wrote:
> Could it be that the problem only happens when including both cpuid.h and
> intrin.h, because they both define __cpuid? (the configure check only
> includes intrin.h)
>
> My theory when I worked on the patch that Michael referenced in
On Monday, July 28, 2025 5:54 PM Amit Kapila wrote:
>
> On Fri, Jul 25, 2025 at 4:38 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Right, I think it makes sense to do with the index scan when the
> > index's xmin is less than the conflict detection xmin, as that can
> > ensure that all the tuples del
On Monday, July 28, 2025 7:43 PM shveta malik wrote:
> On Mon, Jul 28, 2025 at 4:38 PM shveta malik
> wrote:
> >
> > On Fri, Jul 25, 2025 at 4:38 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > >
> > > The V53-0001 also includes Shveta's comments in [1].
> > >
> >
> > Thanks, I have not yet complet
On Mon, Jul 28, 2025 at 12:33 PM Masahiko Sawada wrote:
>
> On Fri, Jul 18, 2025 at 3:05 AM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format implementations"
> > on Thu, 17 Jul 2025 13:44:11 -0700,
> > Masahiko Sawada wrote:
> >
> > >>
On Tue, Jul 29, 2025 at 2:43 AM Doruk Yilmaz wrote:
>
> On Mon, Mar 3, 2025 at 6:39 AM Amit Kapila wrote:
> >
> > To use replication_origin by multiple processes, one must maintain the
> > commit order as we do internally by allowing the leader process to
> > wait for the parallel worker to finis
On Fri, 25 Jul 2025 at 06:46, Cary Huang wrote:
> Thank you so much for the review! I have addressed the comments in the
> attached v7 patch.
I've now spent quite a bit of time going over this patch and testing
it. One issue I found was in heap_set_tidrange() where you were not
correctly setting
Hi Andreas,
On Sun, Dec 22, 2024 at 3:15 AM Andreas Karlsson wrote:
>
> On 10/29/24 8:55 PM, Andreas Karlsson wrote:
> > I especially dislike the static variable in our patch. And as far as I
> > understand it you can avoid the static by changing the lexer to use the
> > push parser so it can emi
On Fri, Jul 25, 2025 at 11:45 AM Masahiko Sawada wrote:
>
> Thank you for testing the patch!
>
> I've reworked the locking part in the patch. The attached v4 patch
> should address all review comments including your previous
> comments[1].
>
Thank You for the patch. I have not reviewed fully, but
David Rowley writes:
> For the record, I 100% agree that there will always be cases where
> statistics are just unable to represent what is discovered at
> run-time, so having some sort of ability to adapt at run-time seems
> like a natural progression on the evolutionary chain. I just don't
> kno
Hello,
I got bitten by an inconsistency introduced about two years ago. In
the script generate-wait_event_types.pl, the intermediate line format
is parsed using a regular expression that allows multiple tab
characters between fields. However, the fields were later extracted
using split(/\t/, ...),
On Fri, 25 Jul 2025 at 11:45, Masahiko Sawada wrote:
>
> On Tue, Jul 22, 2025 at 11:44 PM shveta malik wrote:
> >
> > On Tue, Jul 22, 2025 at 5:03 AM Masahiko Sawada
> > wrote:
> > >
> > > Yes, I agree. The main patch focuses on the part where we
> > > automatically change the effective WAL lev
Alexander Lakhin writes:
> The new check has failed on mamba [1], apparently because this animal is
> too slow for pg_isready:
There is something strange happening on mamba --- not sure what,
but its cycle time for the past week has been a lot more than normal.
I plan to power-cycle it tomorrow a
On Tue, 29 Jul 2025 at 16:01, Richard Guo wrote:
> Another possible direction is to support runtime plan correction or
> feedback loops. We've always followed a "plan-first, execute-next"
> approach so far. But perhaps we could extend that by monitoring plan
> execution and triggering re-optimiz
On Tue, Jul 29, 2025 at 6:30 AM David Rowley wrote:
> On the whole, I don't really see this as a flaw in the Memoize code.
> We've plenty of other cases in the planner that produce inferior plans
> due to lack of enough detail or accuracy of table statistics, so I'm
> not planning on rushing to lo
On Mon, Jul 28, 2025 at 8:26 PM David Rowley wrote:
> I understand not everyone got what they wanted here, but I hope what's
> been added is ok for the majority of people.
>
For what its worth, the last version you posted (v11) looks good to me as
well, and +1 on the "Estimates:" style that puts
Hello Nazir and Michael!
01.07.2025 10:57, Nazir Bilal Yavuz wrote:
I agree with you. So, the current logic is:
If primary is not alive: Do not report anything.
If only primary is alive: Report the entire diff file.
If both primary and standby are alive: Report entire diff file and add
head+tai
On Mon, Jul 28, 2025 at 8:40 PM Tom Lane wrote:
>
> > How isn't that a bug in MinGW itself? I'm puzzled my the macro
> > definition of __cpuid() that reports a conflict. __cpuidex() and
> > __cpuid() are both detected by ./configure, the PG use of __cpuid() in
> > pg_crc32c_sse42_choose.c cause
On Monday, July 28, 2025, jian he wrote:
> On Mon, Jul 28, 2025 at 6:47 PM Vik Fearing
> wrote:
> >
> > > adding these pg_cast entries seems tricky.
>
> select proname, prosrc, proformat from pg_proc where proformat;
>
> what do you think?
>
My first impression of this choice was not good.
How
Michael Paquier writes:
> /usr/share/mingw-w64/include/psdk_inc/intrin-impl.h:2013:42: error:
> macro "__cpuid" requires 5 arguments, but only 2 given
Yeah, surely that's broken ...
> How isn't that a bug in MinGW itself? I'm puzzled my the macro
> definition of __cpuid() that reports a conflic
On Wed, 23 Jul 2025 at 23:08, Ilia Evdokimov
wrote:
> Given that, patch v11 still looks like the most appropriate version to me.
I spent a bit more time cleaning a few things up in this. With all the
complexity from the extra fields, I felt that a round of adjusting the
"double" types so they use
On Mon, Jul 28, 2025 at 6:47 PM Vik Fearing wrote:
>
> > adding these pg_cast entries seems tricky.
> > for example:
> > (assume castsource as numeric, casttarget as text)
> > will
> > (castsource as numeric, casttarget as text, castfunc as numeric_out,
> > castformatfunc as numeric_to_char)
> > e
On Tue, Jul 29, 2025 at 7:23 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > Thanks for your review Kuroda-san, I have changed the logic to not use
> > already_locked and instead check if the locks are taken inside
> > UpdateSubscriptionRelState itself. I've tested this and this works
> > fine. If this lo
On Mon, Jul 28, 2025 at 01:31:15PM +0800, Julien Rouhaud wrote:
> Ah I'm the one apologizing, I totally missed that comment.
>
> Thanks for the pointing it out.
Thanks, no problem.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 29, 2025 at 11:36:35AM +0900, Michael Paquier wrote:
> On Tue, Jul 29, 2025 at 11:21:41AM +0900, Michael Paquier wrote:
> > The attached warrants a backpatch to me, thoughts?
>
> That's of course better with the patch.
So, the CI has accepted to run, and compilation fails with this
fa
Michael Paquier writes:
> While looking at the surroundings, I have noticed a second check
> that's incorrect in ./configure.ac, with __cpuid(). I may be missing
> something, of course, but these two typos have been introduced by
> 3dc2d62d0486, back in 2015. meson is doing these checks correctl
On Mon, Jul 28, 2025 at 02:54:52PM -0400, Bruce Momjian wrote:
> On Mon, Jul 28, 2025 at 03:06:23PM +0200, Daniel Gustafsson wrote:
>> I totally agree that the release notes cannot contain all changes, and lot's
>> of
>> important changes must be left out to make them manageable (the proposed
>>
On Tue, Jul 29, 2025 at 11:21:41AM +0900, Michael Paquier wrote:
> The attached warrants a backpatch to me, thoughts?
That's of course better with the patch.
--
Michael
From de3aa52f66829043fb50957fcd2b6b57c5309220 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 29 Jul 2025 11:20:22 +09
On Mon, Jul 28, 2025 at 03:38:20PM +0900, Michael Paquier wrote:
> On Sun, Jul 27, 2025 at 12:50:54PM -0700, Lukas Fittl wrote:
>> - Fix a typo (configure was incorrectly checking for "__get_cpuidex", vs
>> meson.build was doing it correctly)
>
> It seems to me that this is an independent issue th
Hi all,
While looking at patch 0001 posted by Lukas at [1], the following bit
stood out as an independent fix:
+++ b/configure
unsigned int exx[4] = {0, 0, 0, 0};
- __get_cpuidex(exx[0], 7, 0);
+ __cpuidex(exx, 7, 0);
The patch posted is incorrect because it does not touch configure.ac
and an
Hi,
On 2025-07-29 10:46:16 +0900, Michael Paquier wrote:
> On Mon, Jul 28, 2025 at 03:34:06PM +0300, Nazir Bilal Yavuz wrote:
> > I wanted to show what is in my mind, v4 is attached. Summary is:
> >
> > - 0001 introduces the read_file_ends() function, which reads lines
> > from either the beginni
Dear Ajin,
> Thanks for your review Kuroda-san, I have changed the logic to not use
> already_locked and instead check if the locks are taken inside
> UpdateSubscriptionRelState itself. I've tested this and this works
> fine. If this logic is acceptable to the reviewers I can update the
> other pa
On Mon, Jul 28, 2025 at 03:34:06PM +0300, Nazir Bilal Yavuz wrote:
> I wanted to show what is in my mind, v4 is attached. Summary is:
>
> - 0001 introduces the read_file_ends() function, which reads lines
> from either the beginning or end of a given file. It includes a
> force_line_count argument
On Mon, Jul 28, 2025 at 06:14:20PM +0200, Daniel Gustafsson wrote:
> On 28 Jul 2025, at 17:29, Jacob Champion
> wrote:
>> To move this forward a tiny bit: I would be okay with maintaining a
>> new getentropy() case. (I'm less excited about getrandom() because of
>> its reduced reach.) And maybe d
On Mon, Jul 28, 2025 at 04:16:07PM -0400, Tom Lane wrote:
> Erik's v2 is slightly wrong as to the save-and-restore logic for
> the KeepBlanks setting: we need to restore in the error path too,
> and we'd better mark the save variable volatile since it's modified
> inside the PG_TRY. I made some ot
On Tue, 29 Jul 2025 at 12:11, Matheus Alcantara
wrote:
> By "pushdowns" you mean missing the Run Conditions on the QUALIFY
> example? IIUC the Run Condition is only created if it's a subquery. I've
> checked this on set_rel_size() -> set_subquery_pathlist() ->
> check_and_push_window_quals().
Yes
On 22/07/25 19:32, David Rowley wrote:
> Looking at the latest patch I see that pushdowns don't work:
>
> # explain select row_number() over (order by oid) rb from pg_Class
> qualify row_number () over (order by oid)=1;
>
> # explain (analyze, costs off, buffers off, summary off) select
> row_numbe
On Monday, July 28, 2025, Bruce Momjian wrote:
> On Mon, Jul 28, 2025 at 04:24:14PM -0700, Daniel Bauman wrote:
> > Here's where I think the logging is happening. https://github.com/
> postgres/
> > postgres/blob/master/src/backend/tcop/postgres.c#L1070
> > It seems like the log is happening befo
On Mon, Jul 28, 2025 at 04:24:14PM -0700, Daniel Bauman wrote:
> Here's where I think the logging is happening. https://github.com/postgres/
> postgres/blob/master/src/backend/tcop/postgres.c#L1070
> It seems like the log is happening before application of the transaction, not
> after.
>
> So cons
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Hi,
I've been playing with the patch. It worked as intended. I have a fe
On Monday, July 28, 2025, Jacob Champion
wrote:
> On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston
> wrote:
> > I don’t understand calling out sigterm as an exception, the same
> abort-and-shutdown action happens there too.
>
> RestoreArchivedFile() has a special case for SIGTERM, though?
I d
On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston
wrote:
> I don’t understand calling out sigterm as an exception, the same
> abort-and-shutdown action happens there too.
RestoreArchivedFile() has a special case for SIGTERM, though?
> And in any case signals are turned into exit status values a
On Monday, July 28, 2025, Jacob Champion
wrote:
>
>
> Recovery will abort and the server will not start up if any of the
> following events occur: the command is terminated by a signal other
> than SIGTERM (which is used as part of a database server shutdown);
> the command returns an exit status
On Mon, 28 Jul 2025 at 20:13, Richard Guo wrote:
> create table t (a int, b int, c int);
> insert into t select i%3, i, i from generate_series(1,500)i;
> analyze t;
>
> explain (analyze, costs off, timing off)
> select * from t t1 join lateral
> (select t2.a, t2.b, t1.a x from t t2, t t3 offset
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> Hmm, what about 2c. having pgfdw_report_error() with hardcoded elevel,
> but complement it with pgfdw_report() that takes the elevel as argument,
> asserting that it's less than ERROR? Then the calls look like
> pgfdw_report(WARNING, "doo dee");
> whic
On 2025-Jul-28, Tom Lane wrote:
> 2b. As 2a except the two functions are pgfdw_report_error()
> and pgfdw_report_warning(), both with hard-wired elevel values.
> This'd be sufficient right now, but it's plausible that this path
> would lead to needing pgfdw_report_log() and some other variants
> i
On Mon, Jul 28, 2025 at 1:58 PM Jean-Christophe Arnu wrote:
> Or
>
> The recovery will be aborted and the server will stop if any of the following
> events occur:
> - the command was terminated by a signal other than SIGTERM (which is used as
> part of a database server shutdown);
> - the comman
On 2025-Jul-28, Euler Taveira wrote:
> On Tue, Jul 15, 2025, at 3:30 PM, Álvaro Herrera wrote:
> > Second, in discussion [2] leading to commit 18d67a8d7d30 (Nov 2024) it
> > was agreed to add support for translating backend type descriptions.
> > I'm not really sure that this is useful. It would
On Mon, Mar 3, 2025 at 6:39 AM Amit Kapila wrote:
>
> To use replication_origin by multiple processes, one must maintain the
> commit order as we do internally by allowing the leader process to
> wait for the parallel worker to finish the commit. See comments atop
> replorigin_session_setup(). Now
On Mon, Jul 28, 2025 at 5:34 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> > Thank you for testing the patch!
> >
> > I've reworked the locking part in the patch. The attached v4 patch
> > should address all review comments including your previous
> > comments[1].
>
> Thanks for makin
On Wed, Jul 23, 2025 at 2:12 PM Peter Smith wrote:
>
> On Wed, Jul 23, 2025 at 1:58 PM Japin Li wrote:
> >
> > After some investigation, I found that the VACUUM assertion failures were
> > caused by an uninitialized HeapTupleFreeze structure. PFA.
> >
>
> Hey, great! Thanks very much for your fi
> Attached is my counter-proposal, where I have settled down to four
> categories of PlannedStmt:
> - "standard" PlannedStmt, when going through the planner.
> - internally-generated "fake" PlannedStmt.
> - custom cache
> - generic cache
Thanks for the update! I plan on reviewing this tomorrow.
-
On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote:
>
...
>
> 1.
> I encountered another crash while checking VCI's internal relations.
>
> rm -rf demo
> initdb -D demo
> cat shared_preload_libraries = 'vci'
> max_worker_processes = '20'
> EOF
>
> pg_ctl -D demo start
>
>
Le lun. 28 juil. 2025 à 20:15, Jacob Champion <
jacob.champ...@enterprisedb.com> a écrit :
> I agree that reusing archive_command's wording is probably the way to
> go. I think archive_cleanup_command and recovery_end_command have the
> same issue; opinions on changing those as well?
>
I agree, w
> The current pg_stat_statements change may be a
> good example of the employment of such infrastructure, isn't it?
So, the current set of patches now will help move forward the specific
use-case of this thread. If we need something different that will be
useful for more use-cases, perhaps it's be
Hi all,
On Thu, Jun 26, 2025 at 4:33 PM Jacob Champion
wrote:
> My plan, if this code seems reasonable, is to backport 0001-0003, but
> keep the larger 0004 on HEAD only until it has proven to be stable.
> It's a big new suite and I want to make sure it's not flapping on some
> buildfarm animal.
On Friday 2025-07-11 00:45, Thomas Munro wrote:
On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou wrote:
I applied the patch on PostgreSQL v17 and am testing it now. I chose
ftruncate method and I see ftruncate in action using strace while doing
pg_restore of a big database. Nothing unexpect
I wrote:
> I've not looked at the details of the proposed patches, but will
> do so now that the direction to go in is apparent.
Erik's v2 is slightly wrong as to the save-and-restore logic for
the KeepBlanks setting: we need to restore in the error path too,
and we'd better mark the save variable
Robert Haas writes:
> On Mon, Jul 28, 2025 at 10:55 AM Tom Lane wrote:
>> 2a. Split pgfdw_report_error into two functions, say
>> pgfdw_report_error() that hard-wires elevel as ERROR and is
>> labeled noreturn, and pgfdw_report_noerror() that has an
>> elevel argument that it asserts is less than
On Mon, Jul 28, 2025 at 10:55 AM Tom Lane wrote:
> I can see two, or two-and-a-half, ways to do that:
>
> 1. Wrap pgfdw_report_error in a macro that makes use of pg_unreachable
> in a way similar to what we've done for elog/ereport. The argument
> for this is that we needn't touch the 30-or-so pg
On Tue, Jul 15, 2025, at 3:30 PM, Álvaro Herrera wrote:
>
> We have lists of backend types scattered through the tree. I found two
> current ones, and Euler Taveira wants to add a couple more[1]. His
> patch is actually blocked on not adding more, so this seems worth doing.
> Bikeshedding welcome
On 2/4/25 22:55, Tom Lane wrote:
> Tomas Vondra writes:
>>> The interesting thing about this is we pretty much have all the
>>> infrastructure for detecting such FK-related join conditions
>>> already. Possibly the join order forcing could be done with
>>> existing infrastructure too (by manipula
On Fri, Jul 18, 2025 at 3:05 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 17 Jul 2025 13:44:11 -0700,
> Masahiko Sawada wrote:
>
> >> > How about adding accessors instead of splitting
> >> > Copy{From,To}State to
On Fri, 25 Jul 2025 at 10:38, Nathan Bossart
wrote:
> On Thu, Jul 24, 2025 at 05:39:14PM -0400, Dave Cramer wrote:
> > On Thu, 24 Jul 2025 at 17:05, Jacob Champion <
> > jacob.champ...@enterprisedb.com> wrote:
> >> Since these are part of the replication subprotocol (i.e. tunneled,
> >> via CopyD
On Mon, Jul 28, 2025 at 03:06:23PM +0200, Daniel Gustafsson wrote:
> > On 25 Jul 2025, at 00:22, Bruce Momjian wrote:
> >
> > On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
> >>> On 2 Jul 2025, at 04:51, Steve Chavez wrote:
> >>
> >>> While updating an extension to support 1
On Mon, Jul 28, 2025 at 09:22:29AM -0700, David G. Johnston wrote:
> On Monday, July 28, 2025, Frédéric Yhuel wrote:
>> On 7/28/25 16:47, Nathan Bossart wrote:
>>> Obviously, this wording isn't clear enough. We might need to either
>>> remove that sentence or add "When used in conjunction with
>>
On Mon, Jul 28, 2025 at 11:22:49AM -0400, Robert Haas wrote:
> Committed. I removed the changes from the .po files since we don't
> routinely update those, and I rewrote your proposal commit message.
nitpick: It looks like this needs a pgindent [0].
[0]
https://buildfarm.postgresql.org/cgi-bin/s
On Fri, Jul 25, 2025 at 03:24:48PM -0700, Daniel Bauman wrote:
> Hey pgsql hackers
> This is my first email to this list. I'm reaching out about a possible doc
> update for the log_statement parameter.
> Here's the current doc - https://www.postgresql.org/docs/current/
> runtime-config-logging.html
On Mon, Jul 28, 2025 at 09:22:29AM -0700, David G. Johnston wrote:
> Makes sense. This does beg the question - what happens if a column is left
> with a lower statistics target than what would be applied during an
> analyze, but one is present? I don´t see where the statistics target is
> saved a
Erik Wienhold writes:
> I'm leaning towards Michael's proposal of adding a libxml2 version check
> in the stable branches before REL_18_STABLE and parsing the content with
> xmlParseBalancedChunkMemory on versions up to 2.12.x.
I spent some time investigating this. It appears that even when usin
On Sun, Jul 27, 2025 at 5:48 PM Alexey Makhmutov
wrote:
> The primary goal of this message is just to raise an awareness of this
> change and its possible influence on resulting builds.
I believe that clang works in the same way, and has for some time now.
"clang -mllvm -debug" output shows debug
On Mon, Jul 28, 2025 at 10:48 AM Andres Freund wrote:
> I don't think there's anything special to check for CI specific changes, so I
> guess "... all good" covers it...
Sounds good. I will take another look at this with a committer hat and
push Sometime Soon.
Thanks!
--Jacob
On Mon, Jul 28, 2025 at 8:19 AM Jean-Christophe Arnu wrote:
> You're also right. That's more consistent and easier to read.
> Thank you for pointing this out.
I agree that reusing archive_command's wording is probably the way to
go. I think archive_cleanup_command and recovery_end_command have th
Hi,
On 2025-07-28 09:03:38 -0700, Jacob Champion wrote:
> On Mon, Jul 28, 2025 at 5:08 AM Daniel Gustafsson wrote:
> > Reading over the v6 version posted upthread, I agree with the patch being
> > ready. Are you taking care of it Jacob?
>
> I was admittedly a bit nervous about pushing changes t
Hi Thom!
> On 1 Nov 2024, at 00:25, Thom Brown wrote:
>
> Unfortunately I didn't gather much information when it was occuring, and
> prioritised getting rid of the process blocking replay. I just attached gdb
> to it, got a backtrace and then "print ProcessInterrupts()".
FWIW we diagnosed tha
On Monday, July 28, 2025, Frédéric Yhuel wrote:
>
>
> On 7/28/25 16:47, Nathan Bossart wrote:
>
>> I can't remember who wrote this line, but it was borrowed from the
>> --analyze-in-stages description. The point is that if you use
>> --analyze-in-stages without --missing-stats-only, there will b
> On 28 Jul 2025, at 17:29, Jacob Champion
> wrote:
> To move this forward a tiny bit: I would be okay with maintaining a
> new getentropy() case. (I'm less excited about getrandom() because of
> its reduced reach.) And maybe down the line we should discuss choosing
> an option at configure time
On Mon, Jul 28, 2025 at 12:11:22PM -0400, Bruce Momjian wrote:
> On Fri, Jul 25, 2025 at 10:07:38AM +0200, Fabrice Chapuis wrote:
> > Thank you for your reply, Robert.
> > My main goal was to report this observation, because I was surprised to see
> > that in the dump the grantors were not exported
On Fri, Jul 25, 2025 at 10:07:38AM +0200, Fabrice Chapuis wrote:
> Thank you for your reply, Robert.
> My main goal was to report this observation, because I was surprised to see
> that in the dump the grantors were not exported.
> Thanks for drawing my attention to the "observes" section; it is in
On Mon, Jul 28, 2025 at 5:08 AM Daniel Gustafsson wrote:
> Reading over the v6 version posted upthread, I agree with the patch being
> ready. Are you taking care of it Jacob?
I was admittedly a bit nervous about pushing changes to the infra.
Andres, Bilal, do you have a list of things to check a
On Mon, Jul 28, 2025 at 4:36 AM Daniel Gustafsson wrote:
> There has in the past been discussions (at least off-list in hallway tracks)
> about allowing randomness to be chosen separately from underlying factors such
> as OpenSSL support, at the time it didn't seem worth the trouble but that may
>
On Mon, May 26, 2025 at 7:40 AM Jakub Wartak
wrote:
> v2 attached, rebased and tested.
Committed. I removed the changes from the .po files since we don't
routinely update those, and I rewrote your proposal commit message.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi Jehan-Guillaume,
Le lun. 28 juil. 2025 à 12:32, Jehan-Guillaume de Rorthais
a écrit :
>command not found), then recovery will abort and the server will
> not start
> -up.
> +up. However, the server will also not start if the command returns
> a code
> +of 128 and abo
On 7/28/25 16:47, Nathan Bossart wrote:
I can't remember who wrote this line, but it was borrowed from the
--analyze-in-stages description. The point is that if you use
--analyze-in-stages without --missing-stats-only, there will be a period
where existing statistics will be replaced with one
In the wake of commits 7d8f59577+80aa9848b, Coverity has begun
bleating like this:
*** CID 1659393: Memory - illegal accesses (USE_AFTER_FREE)
/srv/coverity/git/pgsql-git/postgresql/contrib/postgres_fdw/postgres_fdw.c:
4930 in postgresAnalyzeForeignTable()
4924res
On Sun, Jul 27, 2025 at 12:46:44PM +0200, Frédéric Yhuel wrote:
> Then it seems very unlikely that the query optimizer's choices become
> transiently worse because of that, doesn't it? and this shouldn't be used to
> justify this option, IMHO.
I can't remember who wrote this line, but it was borro
Bruce Momjian writes:
> Where do we think our use of libxml2 is heading? Do you suspect
> security scanners will start negative reporting the use of libxml2?
There's at least one distro that's already stopped building with
--with-libxml out of security concerns. (I forget who exactly,
but it's
On Mon, Jul 21, 2025 at 12:46:03PM +0530, Sandeep Thakkar wrote:
>
> On Fri, Jun 20, 2025 at 2:42 AM Tom Lane wrote:
>
> Pavel Stehule writes:
> > Own implementation of SQL/XML generating functions like XMLFOREST or
> > XMLELEMENT should not be too
> > difficult. Significantly m
Stepan Neretin writes:
> However, I couldn’t find the patch or final diff in either the
> pgsql-committers message you linked or as an attachment in the original
> thread.
Commit is here:
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3683af617
The "patch" link on such pages
On Saturday 2025-06-14 18:17, Dimitrios Apostolou wrote:
Out of curiosity I've tried the same with an uncompressed dump
(--compress=none). Surprisingly it seems the blocksize is even smaller.
With my patched pg_restore I only get 4K reads and nothing else on the strace
output.
read(4, "..."
On 26/7/2025 05:09, Richard Guo wrote:
Here, I'd like to discuss whether it's worthwhile to also consider
pushing down a subquery relation's ppi_clauses if the subquery is
LATERAL.
In my opinion, this direction makes sense. Moreover, I have seen
sophisticated cases where SQL Server pushes parame
On 2025-07-28 Mo 8:08 AM, Daniel Gustafsson wrote:
On 17 Jul 2025, at 10:33, Nazir Bilal Yavuz wrote:
On Wed, 16 Jul 2025 at 18:24, Jacob Champion
wrote:
Is there anything else in particular you'd like review on? (I've
marked this patchset RfC.)
Reading over the v6 version posted upthread, I
> On 25 Jul 2025, at 00:22, Bruce Momjian wrote:
>
> On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
>>> On 2 Jul 2025, at 04:51, Steve Chavez wrote:
>>
>>> While updating an extension to support 18beta1, I stumbled on the removal
>>> of `pg_attribute_noreturn()` in favor of
Hi, Oleg!
On Mon, Mar 31, 2025 at 9:48 AM Oleg Tselebrovskiy
wrote:
> 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-chec
> On 27 Jul 2025, at 16:53, Andrey Borodin wrote:
>
> we have to do this "next offset" dance on Primary too.
PFA draft of this.
I also attach a version for PG17, maybe Dmitry could try to reproduce the
problem with this patch. I think the problem should be fixed by the patch.
Thanks!
Best
1 - 100 of 125 matches
Mail list logo
