On Fri, Aug 01, 2025 at 03:16:18PM +0800, Chao Li wrote:
> Ah ... Good to learn. Attached v2 updated the out file as well, now the
> test passed:
>
> $ make check
> ...
> # All 229 tests passed.
That's much better ;)
Applied now down to v18.
--
Michael
signature.asc
Description: PGP signature
Fix typo in foreign_key.sql
Introduced by eec0040c4bcd.
Author: Chao Li
Discussion:
https://postgr.es/m/caeowx2kkmdtwkqiynuwg2l41ywha7g3susrfd9espjwzyx1...@mail.gmail.com
Backpatch-through: 18
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/2106fe25a1c025a75effb7
Fix typo in foreign_key.sql
Introduced by eec0040c4bcd.
Author: Chao Li
Discussion:
https://postgr.es/m/caeowx2kkmdtwkqiynuwg2l41ywha7g3susrfd9espjwzyx1...@mail.gmail.com
Backpatch-through: 18
Branch
--
REL_18_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d0c12b98f2bf741
Mertz, who also originally suggested the solution used in this patch.
Issue introduced by 8c58624df462, so backpatch down to v16.
Author: Ethan Mertz
Co-authored-by: Michael Paquier
Reviewed-by: Amit Kapila
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/aisqqdz7x4laq...@paquier.xyz
Ba
Mertz, who also originally suggested the solution used in this patch.
Issue introduced by 8c58624df462, so backpatch down to v16.
Author: Ethan Mertz
Co-authored-by: Michael Paquier
Reviewed-by: Amit Kapila
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/aisqqdz7x4laq...@paquier.xyz
Ba
Mertz, who also originally suggested the solution used in this patch.
Issue introduced by 8c58624df462, so backpatch down to v16.
Author: Ethan Mertz
Co-authored-by: Michael Paquier
Reviewed-by: Amit Kapila
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/aisqqdz7x4laq...@paquier.xyz
Ba
Mertz, who also originally suggested the solution used in this patch.
Issue introduced by 8c58624df462, so backpatch down to v16.
Author: Ethan Mertz
Co-authored-by: Michael Paquier
Reviewed-by: Amit Kapila
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/aisqqdz7x4laq...@paquier.xyz
Ba
On Fri, Aug 01, 2025 at 03:22:06PM -0700, Masahiko Sawada wrote:
> On Fri, Aug 1, 2025 at 1:58 PM Melanie Plageman
> wrote:
>> Another issue I see is that there are two incorrect tests for a log message
>>
>> # message should not be issued
>> ok( !$node_standby->log_contains(
>> "invalidat
On Fri, Aug 01, 2025 at 02:56:33PM +0800, Chao Li wrote:
> I happened to catch this typo while reading the regression test code, so
> submitting a fix.
>
> As the typo is in the code comment, no test needs to run.
Incorrect. The comment is included in the generated output, impacting
also foreign
On Thu, Jul 31, 2025 at 10:06:02AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I had this lying around as a draft patch, as part of my ongoing campaign
> > to convert many complicated macros to static inline functions. Since
> > the topic was mentioned in another thread [0], I cleaned
On Thu, Jul 31, 2025 at 10:27:37AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
>> In my patch, I just added the missing DatumGetPointer() calls, which
>> seemed easy enough.
>
> I had an earlier patch version that also did that, but it seemed
> kind of verbose to me: adding "_D" is much sh
On Thu, Jul 31, 2025 at 01:17:54PM -0400, Tom Lane wrote:
> My only reservation about 0004 is whether we want to do it like
> this, or with the separate "_D" functions that I proposed in
> the other thread. Right now the vote seems to be 2 to 1 for
> adding DatumGetPointer calls, so unless there a
On Thu, Jul 31, 2025 at 11:52:59AM -0500, Sami Imseih wrote:
> > This means that the configuration parameter (GUC) currently overrides
> > any explicit request for a plan type. The documentation does not clearly
> > explain the rationale behind this, at least to me.
>
> The documentation [0] menti
On Wed, Jul 30, 2025 at 02:05:09PM -0500, Sami Imseih wrote:
> > > The term "NOT_SET" makes me itch a little bit, even if there is an
> > > existing parallel with OverridingKind. Perhaps your proposal is OK,
> > > still how about "UNKNOWN" instead to use as term for the default?
> > +1 to "UNKNOWN
format of the PGSS file did not actually
bother with since 2022..
Author: Sami Imseih
Reviewed-by: Ilia Evdokimov
Reviewed-by: Andrei Lepikhov
Reviewed-by: Michael Paquier
Reviewed-by: Nikolay Samokhvalov
Discussion:
https://postgr.es/m/CAA5RZ0uFw8Y9GCFvafhC=oa8nnmqvzyzxpfv_eepot+iv1t
t value is called
"UNKNOWN", provided as fallback value. This value is not used in the
core code, the idea is to let extensions building their own PlannedStmts
know about this new field.
Author: Michael Paquier
Co-authored-by: Sami Imseih
Discussion: https://postgr.es/m/ailahupxb
On Wed, Jun 04, 2025 at 03:26:24PM +0530, Amit Kapila wrote:
> On Wed, Jun 4, 2025 at 2:39 PM Peter Eisentraut wrote:
>> It's not clear to me how this change now would substantially improve the
>> user experience. The number of characters you type is approximately the
>> same. You still need to
On Wed, Jul 30, 2025 at 03:09:08PM -0500, Sami Imseih wrote:
>> In practice, with this knowledge, we can access the CachedPlanSource of
>> the corresponding PREPARED statement via an extension and override the
>> decision made in 'auto' mode. Unfortunately, we cannot obtain a pointer
>> to plan cac
On Wed, Jul 30, 2025 at 02:03:53PM -0700, Jacob Champion wrote:
> On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut
> wrote:
> > I imagine a "get entropy" operation could be very slow or even blocking,
> > whereas a random number generator might just have to do some arithmetic
> > starting from t
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
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c1984be23cdc3aa74d1fd7bb28a4acaaa6813687
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/1a5212775e46fd573e74c9213392177920f0efd6
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/8de56323c1396626a9d667a0dfe6e1c3a8ca1637
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_18_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cd2d52cc6b394b2e9f11ff870dd727d16765c9c4
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/60953d4cba7cce4a8672b1930d173077ac1130fc
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d6ffc43f95b215fbedba102d343cd31cdd3a5ca7
Modified
t the new reality.
Author: Lukas Fittl
Co-authored-by: Michael Paquier
Discussion: https://postgr.es/m/aigwnygvt5ara...@paquier.xyz
Backpatch-through: 13
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/612f5b80620da0f38b39f48ab545be5c079f621a
Modified
Handle timeout in PostgreSQL::Test::Cluster::is_alive()
This commit adds an extra --timeout=PG_TEST_TIMEOUT_DEFAULT to the call
of pg_isready done in is_alive(), so as it is possible to have more
leverage with the call on machines constrained on resources.
By default the timeout is 180s, and it c
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
ecpg: Fix memory leaks in ecpg_auto_prepare()
This routines includes three code paths that can fail, with the
allocated prepared statement name going out of scope.
Per report from Coverity. Oversight in commit a6eabec6808c, that has
played with the order of some ecpg_strdup() calls in this code
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
Fix performance regression with flush of pending fixed-numbered stats
The callback added in fc415edf8ca8 used to check if there is any pending
data to flush for fixed-numbered statistics, done by looping across all
the builtin and custom stats kinds with a call to have_fixed_pending_cb,
is proving
Fix performance regression with flush of pending fixed-numbered stats
The callback added in fc415edf8ca8 used to check if there is any pending
data to flush for fixed-numbered statistics, done by looping across all
the builtin and custom stats kinds with a call to have_fixed_pending_cb,
is proving
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
Add assertions for all the required index AM callbacks
Similar checks are done for the mandatory table AM callbacks. A portion
of the index AM callbacks are optional and can be NULL; the rest is
mandatory and is documented as such in the documentation and in amapi.h.
These checks are useful to d
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
Fix assertion failure with latch wait in single-user mode
LatchWaitSetPostmasterDeathPos, the latch event position for the
postmaster death event, is initialized under IsUnderPostmaster.
WaitLatch() considered it as a valid wait target in single-user mode
(!IsUnderPostmaster), which was incorrect.
Fix assertion failure with latch wait in single-user mode
LatchWaitSetPostmasterDeathPos, the latch event position for the
postmaster death event, is initialized under IsUnderPostmaster.
WaitLatch() considered it as a valid wait target in single-user mode
(!IsUnderPostmaster), which was incorrect.
Lower bounds related to pgstats kinds
This commit changes stats kinds to have the following bounds, making
their handling in core cheaper by default:
- PGSTAT_KIND_CUSTOM_MIN 128 -> 24
- PGSTAT_KIND_MAX 256 -> 32
The original numbers were rather high, and showed an impact on
performance in pgstat
Lower bounds related to pgstats kinds
This commit changes stats kinds to have the following bounds, making
their handling in core cheaper by default:
- PGSTAT_KIND_CUSTOM_MIN 128 -> 24
- PGSTAT_KIND_MAX 256 -> 32
The original numbers were rather high, and showed an impact on
performance in pgstat
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
now restricted to the current session.
The concept introduced in this commit is useful on its own, and has been
extracted from a larger patch by the same author.
Author: Sami Imseih
Reviewed-by: Andrei Lepikhov
Reviewed-by: Michael Paquier
Discussion:
https://postgr.es/m/CAA5RZ0uFw8Y9GCFvafhC
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 03:35:06AM +, Amit Kapila wrote:
> Preserve conflict-relevant data during logical replication.
>
> Logical replication requires reliable conflict detection to maintain data
> consistency across nodes. To achieve this, we must prevent premature
> removal of tuples delete
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
than the one wanted by the caller, because
it could fallback to default values instead of the parameters defined
depending on the combinations of allocation failures and successes.
Author: Evgeniy Gorbanev
Co-authored-by: Aleksander Alekseev
Reviewed-by: Álvaro Herrera
Reviewed-by: Michael
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
doc: Inform about aminsertcleanup optional NULLness
This index AM callback has been introduced in c1ec02be1d79 and it is
optional, currently only being used by BRIN. Optional callbacks are
documented with NULL as possible value in amapi.h and indexam.sgml, but
this callback has missed this part o
doc: Inform about aminsertcleanup optional NULLness
This index AM callback has been introduced in c1ec02be1d79 and it is
optional, currently only being used by BRIN. Optional callbacks are
documented with NULL as possible value in amapi.h and indexam.sgml, but
this callback has missed this part o
doc: Inform about aminsertcleanup optional NULLness
This index AM callback has been introduced in c1ec02be1d79 and it is
optional, currently only being used by BRIN. Optional callbacks are
documented with NULL as possible value in amapi.h and indexam.sgml, but
this callback has missed this part o
On Thu, Jul 03, 2025 at 01:30:13AM +0900, Fujii Masao wrote:
> BTW, all current index entries point to the top of the pg_buffercache
> docs. Would it be better if each entry pointed directly to its relevant
> section using a zone attribute like this?
>
> -
> +
>pg_buffercache_summary
>
T
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
ecpg: Fix NULL pointer dereference during connection lookup
ECPGconnect() caches established connections to the server, supporting
the case of a NULL connection name when a database name is not specified
by its caller.
A follow-up call to ECPGget_PGconn() to get an established connection
from the
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"
1 - 100 of 7482 matches
Mail list logo
