On Wed, Jul 30, 2025 at 12:02:44PM +0900, Michael Paquier wrote:
> On Tue, Jul 29, 2025 at 12:21:32AM -0700, Lukas Fittl wrote:
>> FWIW, I looked again at the MinGW sources and I think you're right that
>> intrin.h is likely also correct for MinGW. I originally thought that
On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote:
> The only comment I have is I think we need a NOT_SET
> member, so it can simplify the life of extensions that have code
> paths which may or may not have a PlannedStmt, such as
> pgss_store.
Okay by me for having a default that maps to
On Tue, Jul 29, 2025 at 12:21:32AM -0700, Lukas Fittl wrote:
> Its worth noting that __get_cpuid_count and __cpuidex are not fully
> equivalent (which is part of why GCC added __cpuidex despite already
> having __get_cpuid_count), but in any case the current code doesn't care
> about that, since it
e in the
attached? At least that would be more in line with the other tests,
and we'd have more leverage over the timing of is_alive(). Default is
180s.
--
Michael
From 296b63511a77cecc4712e7c790fcac5a88a21bf0 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 29 Jul 2025 15:06:08 +0900
S
piece for your other patch, but for the sake of the
back-branches and what we are doing here it does not seem necessary to
me to do so.
--
Michael
From 7b7d8bc1aa04ee7d8d2d98b9af90c28dc15de580 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 29 Jul 2025 14:
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 compila
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
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 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
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 Mon, Jul 28, 2025 at 08:41:29AM +0200, Andrei Lepikhov wrote:
> It looks good, but doesn't it seem too narrow?
For the use case of the thread which is to count the number of custom
vs generic plans, it would be good enough.
> This minor change allows an extension to track a specific query from
On Sun, Jul 27, 2025 at 12:50:54PM -0700, Lukas Fittl wrote:
> 0001 - Improve the __cpuidex check added for a different purpose
> in 792752af4eb5 to:
>
> - 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 i
On Fri, Jul 25, 2025 at 02:34:07PM -0500, Sami Imseih wrote:
> Sami Imseih writes:
>> I think Michael's got a point. As of HEAD there are seven different
>> places that are setting this to PLAN_CACHE_NONE; who's to say that
>> pg_stat_statements or some other extension might not wish to
>> distin
On Sun, Jul 27, 2025 at 05:19:56PM +0800, Julien Rouhaud wrote:
> heap2_desc apparently inherited the extra bit filtering from heap_desc to
> ignore XLOG_HEAP_INIT_PAGE. But XLOG_HEAP2 only has real opcodes in the
> high bits there is no reason why there should be this filtering, and even if
> it
On Fri, Jul 25, 2025 at 04:27:37PM +0530, Ashutosh Bapat wrote:
> In [1], we decided to document pg_get_multixact_member() in section
> "Transaction ID and Snapshot Information Functions". I think the
> discussion in the email thread applies to this function as well.
Yep, let's be consistent.
> T
On Sun, Jul 27, 2025 at 10:16:47PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> This sentence is incorrect after I have double-checked the behaviors I
>> am seeing based on local builds of libxml2 2.9.7 and 2.9.14.
>
> Hmm, okay, I misread Jim's results then
On Fri, Jul 25, 2025 at 02:21:26PM -0400, Tom Lane wrote:
> I'll be the first to say that I'm not too pleased with it either.
> However, from Jim Jones' result upthread, a "minor update" of libxml2
> could also have caused this problem: 2.9.7 and 2.9.14 behave
> differently. So we don't have sole
On Fri, Jul 25, 2025 at 08:57:29AM +, Bertrand Drouvot wrote:
> This was not needed before fc415edf8ca8, and I think it was better to use
> pgstat_have_pending_wal() to not have to set a flag to every places
> pgWalUsage.XX
> changes.
At the end, this cost makes the separation of the code lay
On Thu, Jul 24, 2025 at 01:44:54PM +0900, Michael Paquier wrote:
> Oh. I like that, and I would like to apply it on HEAD if there are no
> objections.
Done as of 6f22a82a401d.
--
Michael
signature.asc
Description: PGP signature
On Sat, Jul 26, 2025 at 12:26:21AM +0900, Hironobu SUZUKI wrote:
> Even when using EXPLAIN ANALYZE with TIMING=FALSE, the functions
> InstrStopNode(), InstrEndLoop(), and InstrAggNode() in Instrument.c still
> execute code related to the "starttime", "counter", "firsttuple", "startup",
> and "total
On Thu, Jul 24, 2025 at 07:38:46AM +, Bertrand Drouvot wrote:
> On Thu, Jul 24, 2025 at 09:34:45AM +0900, Michael Paquier wrote:
>> These numbers mean that we have enough room for 7 more builtins kinds,
>
> 11 for builtins kinds? (from 13 to 23)
>
> 9 for custom kinds i
On Thu, Jul 24, 2025 at 01:14:47PM -0500, Sami Imseih wrote:
>> Sami Imseih writes:
That is not to say that I think 719dcf3c4 was a good idea: it looks
rather useless from here. It seems to me that the right place to
accumulate these sorts of stats is in CachedPlanSources, and I do
On Fri, Jul 25, 2025 at 01:25:48AM +0200, Jim Jones wrote:
> On 24.07.25 21:23, Tom Lane wrote:
>> However, when testing on RHEL8 with libxml2 2.9.7, indeed
>> I get "Huge input lookup" with our current code but no
>> failure with f68d6aabb7e2^.
>>
>> The way I interpret these results is that in ol
On Wed, Jul 23, 2025 at 12:15:06PM +0900, Michael Paquier wrote:
> A small thing that would be cleaner is to split the patch into two
> parts: one for the in-core backend addition and a second for PGSS.
> Code paths are different, so it's simple to do.
I have been looking at the b
On Wed, Jul 23, 2025 at 12:07:56PM +0800, Japin Li wrote:
> PFA to assert all required IndexAM callbacks are present.
@@ -42,6 +42,19 @@ GetIndexAmRoutine(Oid amhandler)
elog(ERROR, "index access method handler function %u did not return an
IndexAmRoutine struct",
amhandler
On Wed, Jul 23, 2025 at 11:28:38PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> Switching back to the previous code, where we rely on
>> xmlParseBalancedChunkMemory() fixes the issue.
>
> Yeah, just reverting these commits might be an acceptable answer,
> since th
t has been backpatched down to all stable
branches, like f68d6aabb7e2, introducing the regression in all the
stable branches since the minor releases done in August 2024, as of:
12.20, 13.16, 14.13, 15.8, 16.4.
Thoughts or comments?
--
Michael
From 1834a83ec4e013fcc762e07372ca3fa365e2541e Mon Sep 17 00:00
On Tue, Jul 22, 2025 at 01:15:16PM -0500, Sami Imseih wrote:
> The GUC serves multiple purposes. For example,I can create an index as
> invisible
> and use it in a controlled way, which is helpful for experimenting
> with a new index.
An in-core GUC to control the list of indexes that should be a
On Tue, Jul 22, 2025 at 06:04:50PM -0500, Sami Imseih wrote:
> Regardless of what comes out of this thread, pg_hint_plan supporting
> a NoIndexScan hint that takes in an index name, and not only a relname
> is needed. I plan on taking that up there.
Patches are welcome upstream.
--
Michael
signa
On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
>> Noted. I was wondering originally if the threshold for the builtin
>> and custom kinds should be lowered, as well. Perhaps that's just too
>> optimis
On Wed, Jul 23, 2025 at 11:59:11AM -0400, Andres Freund wrote:
> On 2025-07-23 10:23:53 +, Bertrand Drouvot wrote:
>> Indeed, with a single boolean flag, then how could a stat say that it has
>> nothing
>> pending anymore (when flushing) without saying "all the stats have nothing
>> pending" (
On Jul 23, 2025, at 16:33, Bertrand Drouvot
wrote:
> Maybe we could use a flag, say:
>
> #define PGSTAT_PENDING_IO (1 << 0)
> #define PGSTAT_PENDING_WAL(1 << 1)
> #define PGSTAT_PENDING_SLRU (1 << 2)
>
> and check for a pgstat_pending_mask in pgstat_report_stat() instead?
>
> They wo
On Wed, Jul 23, 2025 at 05:04:37AM +, Hayato Kuroda (Fujitsu) wrote:
> While working on [1] I found the point. When recovery_target_lsn is specified
> and
> recovery_target_inclusive is false, recoveryStopsAfter() cannot return true.
>
> /* Check if the target LSN has been reached */
>
On Tue, Jul 22, 2025 at 02:25:13PM -0500, Nathan Bossart wrote:
> I stared at this patch some more and came up with the attached. The
> biggest change is that I've moved the list of built-in LWLock tranches to
> the existing lwlocklist.h file. That simplifies the patch and centralizes
> these lis
On Tue, Jul 22, 2025 at 02:52:49PM -0500, Sami Imseih wrote:
>> We will need a field to store an enum. let's call it CachedPlanType
>> with the types of cached plan. We need to be able to differentiate
>> when cached plans are not used, so a simple boolean is not
>> sufficient.
Guess so.
>> We ca
On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote:
> It seems rather unsurprising that that causes a slowdown.
>
> The pre-check is there to:
> /* Don't expend a clock check if nothing to do */
>
> but you made it way more expensive than a clock check would have been (not
> coun
On Tue, Jul 22, 2025 at 03:28:24PM -0500, Sami Imseih wrote:
> I know Michael opposed the idea of carrying these structures,
> at least CachedPlan, to Executor hooks ( or maybe just not QueryDesc?? ).
> It will be good to see what he think, or if others an opinion about this,
> about
> adding a po
On Tue, Jul 22, 2025 at 02:56:23PM +0200, Hannu Krosing wrote:
> The high-level idea would be to any actual rewrite -- as opposed to
> plain vacuum which frees empty space within the TOAST relation -- as
> part of the vacuum of the main relation.
> Another option would be to store a back-pointer to
On Tue, Jul 22, 2025 at 04:20:53PM +0300, Aleksander Alekseev wrote:
> v7 may have a compilation warning on Linux:
>
> ```
> warning: unused variable ‘alloc_failed’ [-Wunused-variable]
> ```
>
> ... because the only use of the variable is hidden under #ifdef's.
Yep, thanks, didn't see this one c
On Tue, Jul 22, 2025 at 10:02:57AM -0400, Andrew Dunstan wrote:
> Yes, fallout from a system upgrade. Fixed, now, sorry for the noise.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> The patch supports the getrandom() function as a new source of
> pg_strong_random(). The getrandom() function uses the same source as
> the /dev/urandom device but it seems much faster than opening,
> reading, and closing /dev/urand
e772fb9b66baf9e48765d6912c14103b Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 22 Jul 2025 16:03:00 +0900
Subject: [PATCH v7] ecpg: Improve error detection of ecpg_strdup()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This routine ga
On Tue, Jul 22, 2025 at 12:12:25PM +0900, Richard Guo wrote:
> After pushing commit e2debb643 I noticed redis_fdw failure on crake.
>
> +ERROR: failed to connect to Redis: 1
> +CONTEXT: SQL statement "select (select count(*) from
> db15) +
> +(select count(*) from db15
On Thu, Jul 17, 2025 at 01:34:42PM +0800, Japin Li wrote:
> On Wed, 16 Jul 2025 at 10:08, Peter Smith wrote:
>> What's going on there? Is it just an accidentally missing "/* can be
>> NULL */" comment?
>
> It appears commit c1ec02be1d79 is missing the comment.
Agreed. That's user-visible, so ba
On Mon, Jul 21, 2025 at 09:06:59PM -0500, Nathan Bossart wrote:
> On Tue, Jul 22, 2025 at 10:37:05AM +0900, Michael Paquier wrote:
>> This would not choke as long as the old cluster is at least at v10,
>> but well why not.
>
> I'm not sure what you mean. allow_in_plac
On Mon, Jul 21, 2025 at 08:34:41PM -0500, Nathan Bossart wrote:
> I bet we could maintain a decent level of readability with some extra
> commentary. IMHO it's worth it to avoid maintaining duplicate lists. But
> that's not something I feel terribly strong about, if others disagree.
> FWIW I was
On Mon, Jul 21, 2025 at 07:57:32PM -0500, Nathan Bossart wrote:
+if (!defined($ENV{oldinstall}))
+{
+$new->append_conf('postgresql.conf',
+"allow_in_place_tablespaces = true");
+$old->append_conf('postgresql.conf',
+"allow_in_place_tablespaces = true"
On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote:
> I realized that we actually don't trim the file, we do the opposite;
> read the file from both ends. Sorry for not realizing earlier. I will
> update the remaining patches according to that but I think trim_file()
> is helpful, to
On Mon, Jul 21, 2025 at 04:47:31PM -0500, Sami Imseih wrote:
> Last week I published a v11 that adds a field to QueryDesc, but as I thought
> about this more, how about we just add 2 bool fields in QueryDesc->estate
> ( es_cached_plan and es_is_generic_plan ), a field in CachedPlan (
> is_generic_p
On Mon, Jul 21, 2025 at 03:28:14PM -0500, Nathan Bossart wrote:
> On Mon, Jul 21, 2025 at 03:20:55PM -0500, Nathan Bossart wrote:
>> Can we add a note to wait_event_names.txt about the required
>> ordering/matching of the non-predefined LWLocks? Otherwise, these patches
>> look pretty good to me.
On Mon, Jul 21, 2025 at 02:06:03PM +0300, Nikita Malakhov wrote:
> While it is very fast on small data - I see several disadvantages:
> - first of all, VACUUM should be revised to work with such tables;
> - problematic batch insertion due to necessity to store TID chain.
>
> It is just a POC imple
On Mon, Jul 21, 2025 at 02:20:31PM +0300, Nikita Malakhov wrote:
> I agree that storing reltoastrelid in each Toast pointer seems to be
> a waste of disk space since the current Postgres state does not
> allow multiple TOAST tables per relation.
va_toastrelid is a central part of the current syste
On Fri, Jul 18, 2025 at 11:57:07AM +0300, Nazir Bilal Yavuz wrote:
> I added that as 0001. I used a shifting method for the 'tail'
> direction to not use too much memory. I found that there is
> 'File::ReadBackwards' in Perl but you need to install it, so I didn't
> use it.
Some old buildfarm may
On Fri, Jul 18, 2025 at 10:24:12PM +0300, Nikita Malakhov wrote:
> I'm currently debugging POC direct tids TOAST patch (on top of your branch),
> will mail it in a day or two.
Interesting. Of course I may be wrong because I have no idea of how
you have shaped things, still I suspect that for the
On Wed, Jul 16, 2025 at 02:04:12PM +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > depending on what's set in a URI. I think that we need to redesign a
> > bit ecpg_strdup(), perhaps by providing an extra input argument so as
> > we can detect hard failures on OOM and let ECPGconnect() retu
On Tue, Jul 15, 2025 at 10:37:02PM -0700, Nikhil Kumar Veldanda wrote:
> 0001 – pg_compression_available()
> pg_compression_available() in misc.c feels sensible;
Actually, I have taken a step back on this one and recalled that the
list of values available for an enum GUC are already available in
p
On Wed, Jul 16, 2025 at 11:41:09AM +, Bertrand Drouvot wrote:
> On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote:
>> I don't. These names are unlikely to be anywhere other than in the
>> output of queries for any length of time, so if we change them now,
>> nothing will break per
On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote:
>> Hmm. Is that actually useful as we know that the standby has been
>> stalen down when running the test? Even if we report something, we
>> could a
On Wed, Jul 16, 2025 at 09:30:31AM +, Bertrand Drouvot wrote:
> While working on [1], I noticed a discrepancy between lwlock.c and
> wait_event_names.txt for 2 wait events.
Oops.
> Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU
> in
> the C file but MultiXactOff
On Mon, Jun 30, 2025 at 02:45:49PM +0300, Sami Imseih wrote:
> Only changes to the tests due to the revert of nested query
> tracking in f85f6ab051b
@@ -35,6 +36,7 @@ typedef struct QueryDesc
/* These fields are provided by CreateQueryDesc */
CmdType operation;
On Wed, Jun 11, 2025 at 11:42:02AM +0900, Michael Paquier wrote:
> The split of the tests is not completely clean as presented in your
> patch, though. Your patch only does a copy-paste of the original
> file. Some of the basic tests of compression.sql check the
> interactions betwee
On Tue, Jul 01, 2025 at 10:57:11AM +0300, Nazir Bilal Yavuz wrote:
> On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote:
>> One thing I don't yet like is that I think we should report if the primary is
>> alive *before* reporting the diff and skipping reporting it if the primary
>> crashed. It's no
On Wed, Jul 16, 2025 at 08:06:44AM +0800, Junwang Zhao wrote:
> Sorry I didn't mention the reason why I think WITHOUT OIDS should be removed.
>
> WITHOUT OIDS has been a backward-compatible syntax for 6 years, so I
> think maybe not too many users use it nowadays. Besides, there are
> some hints i
On Tue, Jul 15, 2025 at 11:38:09AM -0500, Nathan Bossart wrote:
> On Tue, Jul 15, 2025 at 12:05:07PM -0400, Shayon Mukherjee wrote:
>> Happy to move this to other thread, if it makes more sense, let me know.
>
> Yes, please.
+1 for moving the discussion to the autovacuum thread. Nathan has
propo
On Tue, Jul 15, 2025 at 04:48:05PM +0200, Alexander Kukushkin wrote:
> I totally understand the wish to make pg_stat_statements useful for
> workloads that create/drop a ton of temporary tables.
> However, when pursuing this goal we impacted other types of totally valid
> workloads when tables with
On Tue, Jul 15, 2025 at 09:14:27AM +, Hayato Kuroda (Fujitsu) wrote:
> I put pg_logical_emit_message() after injection_points_wakeup(), but your
> patch
> puts it before. I verified even your patch can reproduce the issue, but is
> there
> a reason?
> (This is not a comment which must be fixe
On Wed, Jul 16, 2025 at 12:38:58AM +0300, Alexander Korotkov wrote:
> I recently got notification this is in Open Items.
> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
> What is your opinion on this: do we need additional hook, fair to
> leave this "as is" or another option?
I'm OK wi
On Tue, Jul 15, 2025 at 09:19:50PM +0300, Alexander Korotkov wrote:
> Thank you for your efforts on this subject. Actually, I was planning
> to work on pushing this after the release freeze ends for v18. I'd
> like to do this at least for tests as they were initially committed by
> me.
>
> Anywa
On Mon, Jul 14, 2025 at 04:03:42PM +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > Should we actually check sqlca_t more seriously if failing one of the
> > strdup calls used for the port, host, etc. when attempting the
> > connection? The ecpg_log() assumes that a NULL value equals a
> > ,
enerated before the checkpoint is completed, leading to the same
result.
With all that said, I'll move on with this stuff once the embargo for
v18 beta2 is lifted and the tag is pushed. That should happen in 24h
or so, I guess.
--
Michael
From 4c920861f07e0f4e6e21e24e5f6a9060054c3232 Mon Se
On Mon, Jul 14, 2025 at 09:01:28AM +0300, Nikita Malakhov wrote:
> Cool, toast tables are subject to bloating in update-heavy scenarios
> and it's a big problem in production systems, it seems there is a promising
> way to solve it once and for all!
>
> Have to mention though that we encountered i
On Mon, Jul 14, 2025 at 02:46:25PM +0800, CAI, Mengjuan wrote:
> Thank you for your reply. I reviewed the thread you mentioned, and
> it seems that the issue needing to be fixed is not the same as the
> one I previously raised.
> I am considering whether the 2PC file check logic in
> PrepareRedoAdd
On Mon, Jul 14, 2025 at 02:35:31PM +0800, jian he wrote:
> here, "text_eq" should be "texteq"?
Yes, I think that you are right here.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 10, 2025 at 02:21:38PM +0900, Michael Paquier wrote:
> After that, I have applied a few cosmetic tweaks here and there, and
> attached is what I have staged for commit, minus proper commit
> messages. The new TAP tests have some WIN32-specific things, and I
> won't b
On Fri, Jul 11, 2025 at 07:22:36PM +0300, Aleksander Alekseev wrote:
> The patch looks correct, but I believe it's incomplete. It misses
> several other places where ecpg_strdup() is called without proper
> checks. A correct patch would look like the one attached.
>
> While working on it I noticed
On Mon, Jun 30, 2025 at 01:21:24PM +0530, Dilip Kumar wrote:
> On Fri, Jun 27, 2025 at 9:29 PM vignesh C wrote:
>> The test execution times are measured in microseconds. In the results
>> table below, the first row indicates the message size, and each value
>> represents the median of 5 test runs.
On Thu, Jul 10, 2025 at 06:58:58PM -0400, Peter Geoghegan wrote:
> On Wed, Jul 9, 2025 at 10:24 PM Noah Misch wrote:
> > Looking at .cirrus.tasks.yml, I bet the key factor is that CI task using
> > debug_parallel_query=regress. I bet the leader is attached to the injection
> > point, but the WARN
On Wed, Jul 09, 2025 at 04:31:31PM +0900, Michael Paquier wrote:
> Attached is a rebased version of the rest, with the recent stanza
> related to fef6da9e9c87 taken into account. 0002 still has a change
> that should be in 0001: I have not really touched the structure of the
> t
On Wed, Jul 09, 2025 at 06:21:05PM -0700, Paul Jungwirth wrote:
> Here is a patch with the new order.
Thanks, done.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 03, 2025 at 12:14:55PM +0530, Rahila Syed wrote:
> #include "miscadmin.h"
> +#include "nodes/execnodes.h"
> #include "nodes/pg_list.h"
> #include "nodes/value.h"
>
> Do we need to include this? I did not see any compilation error when I
> removed this.
Right, this one was not neede
On Wed, Jul 09, 2025 at 03:46:43PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> Seems like we should just remove TransactionIdIsActive()?
>
> +1. I wondered if any extensions might depend on it, but
> could not find any trace of that in Debian code search.
> And it's a sufficiently odd test
On Wed, Jul 09, 2025 at 01:52:08PM -0400, Tom Lane wrote:
>> I considered putting the sortsupport functions first, since they have a
>> lower support function
>> number, but I thought defining them in the same order as we've been doing
>> was a tiny bit safer.
>> Maybe that is superstitious.
>
the
two remaining patches yet.
--
Michael
From 19d59646e1842ffd73aa0d79fc80c89370878f60 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 9 Jul 2025 16:17:36 +0900
Subject: [PATCH v12 1/2] servicefile option usage on connection string feature
and its tests.
---
src/interfaces/libpq/fe-
On Tue, Jul 08, 2025 at 05:41:32PM -0700, Noah Misch wrote:
> I'd prefer not to get involved in decisions affecting only psql efficiency and
> psql code cosmetics. Please make that decision without my input.
Okay, I have used this more extensible routine then, planning to use
it for the other pat
On Wed, Jul 09, 2025 at 02:39:22AM +, Hayato Kuroda (Fujitsu) wrote:
> +# Some GUCs like track_commit_timestamp cannot be set to non-default value in
> +# bootstrap mode becasue they may cause crash. Ensure settings can be surely
> +# ignored.
> +command_ok(
> + [
> + 'initd
On Tue, Jul 08, 2025 at 03:25:26PM +, Bertrand Drouvot wrote:
> So, something like:
>
> ClassInfo LWLockClassInfo = {
> .numberOfEvents = NB_LWLOCK_WAIT_EVENTS,
> .pendingCounts = PendingWaitEventStats.lwlock_counts
> };
>
> and then the "global" one:
>
> WaitClassInfo *AllWaitClasse
On Tue, Jul 08, 2025 at 04:49:30PM -0700, Paul Jungwirth wrote:
> I noticed that the comment at the top of btree_gist--1.8--1.9.sql says it is
> the 1.7--1.8 file. Here is a one-line patch to fix that.
>
> A related question: In the v18 release we are adding two upgrade files:
> btree_gist--1.7--1
On Tue, Jul 08, 2025 at 05:50:59PM +0200, Antonin Houska wrote:
> ok, I assume you mean that the requirement for ABI/API stability would make it
> hard to include tests for fixes like [2] in minor releases. Thanks for
> explanation.
You can think about it the same way as we do for regress.so, for
On Tue, Jul 08, 2025 at 05:40:39PM +0300, Florents Tselai wrote:
> On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut wrote:
>>> +
>>> +Below are some checklists for common scenarios.
>>> +
>>> +## Adding a New Built-in SQL Command
>>> +
>>> +1. Implement the function in C and place it in the approp
On Tue, Jul 08, 2025 at 12:58:26PM -0400, Burd, Greg wrote:
> All that aside, I think you're right to tackle this one step at a
> time and try not to boil too much of the ocean at once (the patch
> set is already large enough). With that in mind I've read once or
> twice over your changes and have
On Tue, Jul 08, 2025 at 09:31:29PM +0300, Nikita Malakhov wrote:
> Michael, one more thing forgot to mention yesterday -
> #define TOAST_EXTERNAL_INFO_SIZE (VARTAG_ONDISK_OID + 1)
> static const toast_external_info
> toast_external_infos[TOAST_EXTERNAL_INFO_SIZE]
> VARTAG_ONDISK_OID historically ha
On Tue, Jul 08, 2025 at 08:54:33PM +0200, Hannu Krosing wrote:
> I still think we should go with direct toast tid pointers in varlena
> and not some kind of oid.
>
> It will remove the need for any oid management and also will be
> many-many orders of magnitude faster for large tables (just 2x fast
On Sat, Jul 05, 2025 at 02:00:07PM -0400, Tom Lane wrote:
> Here's a fleshed-out implementation of Hayato-san's idea. I've
> not done anything about reverting 5a6c39b6d, nor have I done any
> checks to see if there are other GUCs we ought to mark similarly.
> (But at this point I'd be prepared to
On Mon, Jul 07, 2025 at 08:00:01AM +0300, Alexander Lakhin wrote:
> I'm sorry for not being accurate enough -- I forgot to mention that I
> replicated the config from culicidae, and now I see that "fsync=on"
> is needed to reproduce the failure for me (though maybe).
Even with that, the situation
On Mon, Jul 07, 2025 at 03:07:12PM +, Bertrand Drouvot wrote:
> On Mon, Jul 07, 2025 at 02:56:29PM +0900, Michael Paquier wrote:
>> On Mon, Jun 30, 2025 at 01:36:12PM +, Bertrand Drouvot wrote:
>
> Yeah, I think that this is needed for the custom wait events. But do we need
On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote:
> I think the choice to make there is whether to call PQconninfo() once per
> prompt emission or to cache the value, invalidating that cache e.g. once per
> SyncVariables(). My first thought was to cache, but the decision is not too
> imp
1 - 100 of 2621 matches
Mail list logo
