Hello,
Updating code to satisfy compiler warnings about unused code.
Cheers,
Boris
v4-pgbench-faster-modes.patch
Description: v4-pgbench-faster-modes.patch
>
>
>
>> My apologies for the delayed response.
>>
>
> Valuable responses are worth waiting for.
>
I've reorganized some things a bit, mostly to make resource cleanup
simpler.
From c387c379f4a8ba83073fd3e8d697368fe3250aa4 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Thu, 7 Aug 2025 23:58:38
On Sat, Nov 22, 2025 at 03:26:19AM -0500, Corey Huinker wrote:
> I'm open to it, but there was significant pushback to having tight validity
> checks on other stats types.
Yeah, I am not sure that there is much value in having strict checks
for the values. Some control over the arguments listed i
Hi,
Attaching the rebased patch after resolving some recent conflicts.
Thanks & Regards,
Sunil Seetharama
v10-0001-Introduce-feature-to-start-WAL-receiver-eagerly.patch
Description: Binary data
v10-0002-Test-WAL-receiver-early-start-upon-reaching-cons.patch
Description: Binary data
v10-0003
Hi ChangAo,
At 2025-11-23 13:31:49, "cca5507" wrote:
>> The patch in attachment is better for me. What do you think?
>
>The v2-0001 LGTM.
>
>A small suggestion:
>
>We should move the 'break' out of the 'if', because we don't want it fall
>through to XLOG_HEAP2_REWRITE if we are fast-forwarding.
On Sun, Nov 23, 2025 at 01:44:18AM +, * Neustradamus * wrote:
> Links of XEPs are here to confirm that "tls-exporter" is needed and
> already used.
How are XEPs relevant to PG?
> Several people would like to deprecate "tls-server-end-point" (RFC
> 5929) like Simon Josefsson (author of several
Hi,
Sorry for the direct CC.
Given your expertise in logical replication and your dedication to improving
its functionality,
I think the issue mentioned in [1] may be worth some attention. If you have
time, I am appreciate
your thoughts or opinions on the issue.
Thanks and sorry again fo
> On Nov 12, 2025, at 21:57, John Naylor wrote:
>
> I decided I wasn't quite comfortable with the full normalized datum
> sharing space in SortTuple with isnull1. There's too much of a
> cognitive burden involved in deciding when we do or don't need to
> reset isnull1, and there's a non-zero ris
Hi Haiyang,
> The patch in attachment is better for me. What do you think?
The v2-0001 LGTM.
A small suggestion:
We should move the 'break' out of the 'if', because we don't want it fall
through to XLOG_HEAP2_REWRITE if we are fast-forwarding.
--
Regards,
ChangAo Chen
On Sun, Nov 23, 2025 at 12:27:08PM +0800, Chao Li wrote:
> 1. "This loop stores into os_page_ptrs[]” is understandable, but
> feels a bit incomplete to me as non-English-speaking. I understand
> your intention is to make “stores” and “touches” to share
> “addresses”. But this is not a strong opinio
Hi,
This patch improves the user experience when working with COPY commands by
adding helpful error hints for invalid options.
Currently, when users make typos in COPY option names or values, they
receive
a generic error message without guidance on what went wrong. This patch adds
two types of hi
> On Nov 21, 2025, at 19:34, Bertrand Drouvot
> wrote:
>
> Hi hackers,
>
> While working on [1], I noticed that there are unused fields in
> BufferCacheNumaRec
> since ba2a3c2302f.
>
> Also, I noticed that a comment was not at the correct location in
> pg_buffercache_numa_pages().
>
> Th
Thomas Munro writes:
> That'd leave only Cygwin with HAVE BUGGY_STRTOF. Perhaps they have
> fixed their implementation[1]? Here's an experimental patch to drop
> all remnants, which could be used to find out. No Windows/Cygwin
> here. Hmm, what if we just commit it anyway? If their strtof() i
On Wed, Nov 19, 2025 at 3:13 PM Thomas Munro wrote:
> I was also curious to know if the nearby floating point formatting
> kludge added by commit f1885386 was still needed today. CI passes
> without it, and the standard is pretty clear: "The exponent always
> contains at least two digits, and onl
Hi ChangAo,
Thanks for your analyze and report.
At 2025-11-23 00:07:59, "cca5507" wrote:
>The main reason is that we don't handle XLOG_HEAP2_NEW_CID during
>fast-forwarding, so we don't consider the insert as having a catalog change.
Yeah. Refers to code below:
```
case XLOG_HEAP2_NEW_CID:
Hello Nico,
Thanks for your answer!
Links of XEPs are here to confirm that "tls-exporter" is needed and already
used.
XEPs are already supported by a lot of projects/softwares/companies in
production, for example on GitHub, we can see:
-
https://github.com/search?q=XEP-0480+-repo%3Axsf%2Fxeps
Paul A Jungwirth writes:
> The reason for supporting more than SQL functions is to let you
> construct the query dynamically, e.g. with user-supplied table/column
> names, or to only include some expensive filters if needed. This would
> be great for building functions that implement temporal
> ou
On Tue Nov 18, 2025 at 11:19 AM EST, Robert Haas wrote:
> Here's v4. This version has some bug fixes and test case changes to
> 0005 and 0006, with the goal of getting CI to pass cleanly (which it
> now does for me, but let's see if cfbot agrees).
Thanks for working on this, Robert! I think the de
On Fri, Nov 21, 2025 at 11:34:01AM +, Bertrand Drouvot wrote:
> While working on [1], I noticed that there are unused fields in
> BufferCacheNumaRec
> since ba2a3c2302f.
>
> Also, I noticed that a comment was not at the correct location in
> pg_buffercache_numa_pages().
>
> The attached tak
On Sat, Nov 22, 2025 at 03:16:44PM +0100, Alvaro Herrera wrote:
> ExecDropSingleTupleTableSlot(existing_slot);
> + INJECTION_POINT("check-exclusion-or-unique-constraint-no-conflict",
> &conflict);
>
> However, I don't see that the SQL injection point interface has the
> ability to r
On 22/11/2025 19:37, Tom Lane wrote:
> After sleeping on it, I'm inclined to word the notice like
>
> NOTICE: function "f" will be effectively temporary
> DETAIL: It depends on temporary .
I changed the error level to NOTICE:
postgres=# CREATE TEMPORARY TABLE temp_table AS SELECT 1 AS val;
> > nworkers has a double meaning. The return value of
> > AutoVacuumReserveParallelWorkers
> > is nreserved. I think this should be
> >
> > ```
> > nreserved = AutoVacuumReserveParallelWorkers(nworkers);
> > ```
> >
> > and nreserved becomes the authoritative value for the number of parallel
> > w
Okay,
With the new MSVC compiler flag Andres mentioned (/arch:armv9.4) I only
had to update the S_UNLOCK() macro, the compiler did the rest correctly
AFAICT. So, a much smaller patch (v2) attached. FWIW I'm using Visual
Studio 2026 (18) to build, other platform information below [1].
The white s
On Thu, Nov 20, 2025, at 21:26, Tom Lane wrote:
> I took a brief look through the v28 patch, and I'm fairly distressed
> at how much new logic has been stuffed into what's effectively a
> critical section. It's totally not okay for AtCommit_Notify or
> anything it calls to throw an error
Right, I
Also, we do have custom claims (we should publish a spec and register
them at IANA...) for very coarse-grained authorization that amounts to
an application-level firewall logic that lets us isolate workloads by
type (think prod vs QA vs dev, but also other things).
No OAuth library on the server s
Hi,
On Sat, Nov 1, 2025 at 3:03 AM Masahiko Sawada wrote:
>
> On Tue, Oct 28, 2025 at 6:10 AM Daniil Davydov <[email protected]> wrote:
> >
> > I'll allow it for a/v leader. I've also thought about
> > "compute_parallel_delay".
> > The simplest solution that I see is to move cost-based delay
On Sat, Nov 22, 2025 at 06:28:13AM -0500, Robert Haas wrote:
> What would be an issue is if we
> regressed some kind of common pattern. I admit that's a bit
> speculative and I'm probably being a little paranoid here: doing smart
> things is typically better than doing dumb things, and what we're
>
Tom Lane wrote:
>if a temp table is used to
> define an old-style function's argument or result type, eg
> create function get_mytable() returns setof mytable as ...
> This is problematic because the function will go away when mytable
> does, no matter how its body is expressed.
I briefly
On Sat, Nov 22, 2025 at 10:25:48AM -0500, Robert Haas wrote:
> On Thu, Nov 20, 2025 at 6:09 PM Nathan Bossart
> wrote:
>> Unpinning/detaching the segment/DSA/dshash table and deleting the DSM
>> registry entry in a PG_CATCH block scares me a little, but it might be
>> doable.
>
> It seems a bit
On Fri, Nov 21, 2025 at 05:26:52PM -0500, Andrew Dunstan wrote:
> > I agree, of course, that we shouldn't
> > randomly sandwhich a bunch of disparate values into a single GUC --
> > several separate GUCs is better. However, what about a value that
> > intrinsically has some internal structure? We o
On Fri, Nov 21, 2025 at 5:26 PM Andrew Dunstan wrote:
> One of the things that bothers me a bit here is that we seem to be
> inventing a bunch of micro-languages to deal with structured GUC data.
> Maybe they could all be JSON?
I can understand why you (or anyone) would suggest this, but I don't
Jim Jones writes:
> On 22/11/2025 00:46, Tom Lane wrote:
>> Although I've left the patch throwing an error (with new wording)
>> for now, I wonder if it'd be better to reduce the error to a NOTICE,
>> perhaps worded like "function f will be effectively temporary due to
>> its dependence on ".
> I
On Sat, Nov 22, 2025 at 12:28 PM Sami Imseih wrote:
> What I have not been able to prove from my tests is that the processing
> order of tables by autovacuum will actually make things any better or any
> worse. My tests have been short 30 minute tests that count how many
> vacuum cycles tables wit
Tom Lane wrote:
> No, that's not part of the proposal. The one case in which we'd
> complain (at an error level TBD) is if a temp table is used to
> define an old-style function's argument or result type
Thank you, I see I was being an idiot.
Bernice Southey writes:
> Yikes. Can I get in early on the push-back? I think what you're saying
> is you want to stop old-style SQL functions from using temp tables
> that exist outside of them?
No, that's not part of the proposal. The one case in which we'd
complain (at an error level TBD) is
> > I suspect the most likely area the new prioritisation order could
> > cause issues is from the lack of randomness. Will multiple workers
> > working into the same database be more likely to bump into each other
> > somehow in a bad way? Maybe that's a good area to focus testing.
>
> I agree tha
On Sat, Nov 22, 2025 at 4:01 PM Tom Lane wrote:
> The big change is that it makes zero sense to me to apply this
> restriction only to new-style SQL functions. If it's bad for an
> allegedly non-temporary function to disappear at session exit,
> surely it's not less bad just because it's old-styl
On Fri, Nov 21, 2025 at 01:13:50PM +0100, Peter Eisentraut wrote:
> On 21.11.25 01:49, Bruce Momjian wrote:
> > Actually, another discussion would be why we have src/tools/codelines in
> > the git tree at all. I added it in 2005 to use in counting code lines,
> > and I thought we could consider it
Hi ChaoAo,
At 2025-11-22 18:34:23, "cca5507" wrote:
>One important thing is that we must not skip any call to
>ReorderBufferXidSetCatalogChanges() (direct or indirect) during
>fast-forwarding or building snapshot, because the historic snapshot only
>tracks txns with catalog changes, the v6-0004
On Thu, Nov 20, 2025 at 6:09 PM Nathan Bossart wrote:
> Unpinning/detaching the segment/DSA/dshash table and deleting the DSM
> registry entry in a PG_CATCH block scares me a little, but it might be
> doable.
It seems a bit weird to be doing explicit unpinning in a PG_CATCH
block. Ideally you'd w
Hello,
On 2025-Nov-22, Mihail Nikalayeu wrote:
> I attached an updated version, changes are:
> 1) your fix for comment
> 2) some updates for 0001 test stability (related to [0]).
Thank you. I've been looking at this part of 0001 too:
> @@ -942,6 +943,8 @@ retry:
> econtext->ecxt_scantu
On Sat, Nov 22, 2025 at 10:31 AM Chao Li wrote:
>
>
>
> > On Nov 22, 2025, at 00:14, Fujii Masao wrote:
> >
> > On Fri, Nov 21, 2025 at 6:24 PM Chao Li wrote:
> >> No, what I was thinking is that, we could combine the three set statement
> >> into one, like:
> >>
> >> ```
> >> Set a = 1; set b
Hello, Álvaro!
> Hello, I'm working on getting the 0002 fix committed, with the tests it
> fixes. I ran across this comment:
Nice!
> Am I understanding this correctly?
Yes, you are right. Looks like I mixed up everything while writing the comment.
I attached an updated version, changes are:
1)
On 22/11/2025 00:46, Tom Lane wrote:
> Jim Jones writes:
>> PFA v6 with these changes.
>
> I went through this and made one big change and some cosmetic ones.
>
> The big change is that it makes zero sense to me to apply this
> restriction only to new-style SQL functions. If it's bad for an
On 2025-Nov-21, Daniel Gustafsson wrote:
> > On 21 Nov 2025, at 12:33, Aleksander Alekseev
> > wrote:
>
> > Are there good reasons why we can't simply make lz4 a required
> > dependency? In the worst case we could simply copy its implementation,
> > the license permits.
>
> I think we should,
On Thu, Nov 20, 2025 at 9:55 PM Nathan Bossart wrote:
>
Thanks for working on this problem, We frequently hear about the auto
vacuuming scheduling issue. I believe this is a great starting point
to prioritize based on the wraparound and vacuum threshold limit.
However, my vision for addressing
On 2025-Nov-21, Daniel Gustafsson wrote:
> The attached v2 adds a GUC debug_exec_backend which can be used to get the
> state of the running cluster,
Nice idea.
I think the parallel to debug_assertions is not perfect, because you can
turn off debug_assertions in a server built with them included
Hi!
(sorry, I accidentally pressed "reply" instead "reply all) - sent again
Michael Paquier wrote:
>
> FWIW, I think that it's OK to use as style. The backend-side
> injection point implementation is currently quite simple, meaning that
> it less prone to future bugs. For testing purposes, tha
Hi,
Length of indexcollations[] in `IndexOptInfo` is nkeycolumns, but
struct comments fail to express this, it says:
indexkeys[], indexcollations[] each have ncolumns entries.
So we should polish this description. trivial patch attached.
--
Regards
Junwang Zhao
0001-indexcollations-length-sh
On 2024-Aug-24, Michail Nikolaev wrote:
Hello, I'm working on getting the 0002 fix committed, with the tests it
fixes. I ran across this comment:
> @@ -813,7 +814,13 @@ infer_arbiter_indexes(PlannerInfo *root)
> idxRel = index_open(indexoid, rte->rellockmode);
> idxFo
On Thu, Nov 20, 2025 at 5:12 PM David Rowley wrote:
> It wasn't intended to be offensive.
OK.
> I suspect the most likely area the new prioritisation order could
> cause issues is from the lack of randomness. Will multiple workers
> working into the same database be more likely to bump into each
Hello,
Adding tests for new modes into Perl testing framework for pgbench.
The goal is to pass GitHub checks for the patch in green to simplify reviewer's
life.
Cheers,
Boris
v3-pgbench-faster-modes.patch
Description: v3-pgbench-faster-modes.patch
Hi Haiyang,
Thank you for your summary.
One important thing is that we must not skip any call to
ReorderBufferXidSetCatalogChanges() (direct or indirect) during fast-forwarding
or building snapshot, because the historic snapshot only tracks txns with
catalog changes, the v6-0004 seems to skip
Hi
only rebase
Regards
Pavel
From 65dacc20db9dd3a019e8babdb2fb602490804f05 Mon Sep 17 00:00:00 2001
From: "[email protected]"
Date: Sun, 16 Jun 2024 15:52:38 +0200
Subject: [PATCH 3/3] set plpgsql.extra_errors to "none"
Purpose of previous commit was to run tests with active strict_expr_check.
Hi Ajin & Bertrand,
I missed CC you in last email. Just for your infomation. No defence.
Best regards,
Haiyang Li
Hi Daniel,
I just reviewed the patch and got a few comments.
> On Nov 22, 2025, at 06:38, Daniel Gustafsson wrote:
>
>
> The attached v2 adds a GUC debug_exec_backend which can be used to get the
> state of the running cluster, much like how debug_assertions will tell whether
> or not assertio
Hi all,
I would like to share a logical replication bug and some possible fixes. It
seems that this bug has existed since
logical replication was first introduced, so it has been around for quite some
time. In fact, the previously
reported issues [1], [2], [3] were all caused by this bug.
# P
On 19.11.25 19:49, Paul A Jungwirth wrote:
On Thu, Nov 13, 2025 at 8:10 PM Chao Li wrote:
I continue reviewing ...
Thank you for another detailed review! New patches are attached (v61),
details below.
I have committed 0001 and 0003 from this set. I will continue reviewing
the rest.
Hi,
When working on another historic snapshot's bug in [1], I find the $subject.
Here is a test case, but we need to add some log in SnapBuildSerialize() first:
diff --git a/src/backend/replication/logical/snapbuild.c
b/src/backend/replication/logical/snapbuild.c
index 6e18baa33cb..6d13b2d811b
On Fri, Nov 21, 2025 at 11:48 PM Peter Eisentraut wrote:
> Currently, headerscheck and cpluspluscheck are very slow, and they
> defeat use of ccache. I have fixed that, and now they are much faster. :-)
>
> The problem was (I think) that the test files are created in a
> randomly-named directory
On Tue, Nov 18, 2025 at 4:06 AM Thomas Munro wrote:
> Looks good so far. Will try to push this tomorrow.
Pushed. Thanks Holger and Anthonin.
> I got distracted trying to figure out why LLVM 22 is segfaulting in
> llvm::orc::ExecutionSession::IL_emit(). It's not out ... yet. I was
> worried t
On 2025-Nov-21, Andres Freund wrote:
> On 2025-11-21 13:14:18 +0100, Álvaro Herrera wrote:
> > So how bad is the effect of the cache pollution that's now going to
> > occur?
>
> I don't think there's any cache pollution after this change - the
> pollution the comment was referencing was that cca
Hi,
On Sat, 22 Nov 2025 at 01:16, Andrew Dunstan wrote:
>
> On 2025-07-18 Fr 3:19 AM, Ashutosh Bapat wrote:
> > Hi All,
> >
> > On Mon, Jan 27, 2025 at 11:22 AM Ashutosh Bapat
> > wrote:
> >> On Mon, Nov 25, 2024 at 7:06 PM Nazir Bilal Yavuz
> >> wrote:
> >>> It is added and marked as ready fo
63 matches
Mail list logo
