On Wed, Jul 9, 2025 at 10:09 PM Masahiko Sawada wrote:
> Thank you for reviewing the patches. I've just pushed the fix.
Thanks for pushing them!
On Wed, May 28, 2025 at 5:55 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I probably had to start with a statement that I find the current approach
> reasonable, and I'm only curious if there is more to get out of it. I haven't
> benchmarked the patch yet (plan getting to it when I'll get ba
On Sun, May 25, 2025 at 2:34 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I see thanks. Indeed, there isn't much difference between what I had in
> mind and the relevant bits in 0004, so probably it's the way to go.
Done.
On Fri, Jul 11, 2025 at 9:48 PM David E. Wheeler
wrote:
> On Jul 10, 2025, at 19:23, David E. Wheeler wrote:
>
> > Now with the `ISO C90 forbids mixed declarations and code` warning
> cleared up.
> >
> > Weird that there’s a failure on Bookworm with Meson [1] (pg_regress
> diffs [2]) but not Boo
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 7/11/25 11:50, Rustam ALLAKOV wrote:
Hi Paul,
Thanks for this patch!
Lilian and I have reviewed your patches.
Thank you for the review! I've attached new patches addressing your feedback.
All patches apply and all tests are passing.
Since you are adding tests, we expected to see some impro
On Fri, Jul 11, 2025 at 04:32:13PM -0500, Sami Imseih wrote:
> Now, what I think will be a good API is to provide an alternative to
> LWLockRegisterTranche,
> which now takes in both a tranche ID and tranche_name. The new API I propose
> is
> LWLockRegisterTrancheWaitEventCustom which takes only a
Hi Nathan,
> I just noticed $SUBJECT. This seems to be an oversight in commit 2fc7af5,
> which simultaneously combined ckptXidEpoch and ckptXid into ckptFullXid
and
> removed the only use of that information, i.e., GetNextXidAndEpoch(). Any
> objections if I remove it now?
Good catch. I don't s
> > and instead reuse the existing static hash table, which is
> > capped at 128 custom wait events:
> >
> > ```
> > #define WAIT_EVENT_CUSTOM_HASH_MAX_SIZE 128
> > ```
>
> That's probably still high enough, thoughts?
I have no reason to believe that this number could be too low.
I am not aware of
On Wed, Jul 09, 2025 at 04:39:48PM -0500, Sami Imseih wrote:
> Attached is a proof of concept that does not alter the
> LWLockRegisterTranche API.
IMHO we should consider modifying the API, because right now you have to
call LWLockRegisterTranche() in each backend. Why not accept the name as
an a
I just noticed $SUBJECT. This seems to be an oversight in commit 2fc7af5,
which simultaneously combined ckptXidEpoch and ckptXid into ckptFullXid and
removed the only use of that information, i.e., GetNextXidAndEpoch(). Any
objections if I remove it now?
--
nathan
>From 19a915582492a2a6a02a0c98
On Fri, Jul 11, 2025, at 2:50 PM, Nathan Bossart wrote:
> On Fri, Jul 11, 2025 at 01:26:53PM -0400, Greg Burd wrote:
>> This change does remove the have_free_buffer() function used by the
>> contrib/pg_prewarm module. On the surface this doesn't seem to cause any
>> issues, but honestly I've not
Hi,
On 2025-07-11 13:26:53 -0400, Greg Burd wrote:
> In conversations [1] recently about considering how best to adapt the code
> to become NUMA-aware Andres commented, "FWIW, I've started to wonder if we
> shouldn't just get rid of the freelist entirely" and because I'm a glutton
> for punishment
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Paul,
Thanks for this patch!
Lilian and I have reviewed yo
On Fri, Jul 11, 2025 at 01:26:53PM -0400, Greg Burd wrote:
> This change does remove the have_free_buffer() function used by the
> contrib/pg_prewarm module. On the surface this doesn't seem to cause any
> issues, but honestly I've not thought too deeply on this one.
Hm. ISTM we'll either need t
On Jul 10, 2025, at 19:23, David E. Wheeler wrote:
> Now with the `ISO C90 forbids mixed declarations and code` warning cleared up.
>
> Weird that there’s a failure on Bookworm with Meson [1] (pg_regress diffs
> [2]) but not Bookworm with Configure [3]. Collation issue, perhaps?
David Johnson
Hi,
David G. Johnston" writes:
> On Friday, July 11, 2025, Zhang Mingli wrote:
>> So, are both result sets technically correct given the absence of an ORDER
>> BY clause?
> The system is behaving within the requirements of the specification. The
> query itself is bugged code that the query aut
> On Jul 10, 2025, at 8:13 AM, Burd, Greg wrote:
>
>
>> On Jul 9, 2025, at 1:23 PM, Andres Freund wrote:
>>
>> Hi,
>>
>> On 2025-07-09 12:55:51 -0400, Greg Burd wrote:
>>> On Jul 9 2025, at 12:35 pm, Andres Freund wrote:
>>>
FWIW, I've started to wonder if we shouldn't just get rid
On Thu, Jul 10, 2025 at 7:41 AM wrote:
> I agree with the patch. Works in my OSes
Thanks Ivan! Committed.
--Jacob
Hello,
In conversations [1] recently about considering how best to adapt the code to
become NUMA-aware Andres commented, "FWIW, I've started to wonder if we
shouldn't just get rid of the freelist entirely" and because I'm a glutton for
punishment (and I think this idea has some merit) I took hi
Committed.
--
nathan
Hi Evgeniy,
> In case of out_of_memory, the ecpg_strdup function may return NULL.
> Checks should be added in src/interfaces/ecpg/ecpglib/execute.c.
> Patch attached.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
The patch looks correct, but I believe it's incomplete. It m
Hi,
On 2025-07-10 14:17:21 +, Bertrand Drouvot wrote:
> On Wed, Jul 09, 2025 at 03:42:26PM -0400, Andres Freund wrote:
> > I wonder if we should *increase* the size of shared_buffers whenever huge
> > pages are in use and there's padding space due to the huge page
> > boundaries. Pretty pointl
Hi,
On 2025-07-10 17:31:45 +0200, Tomas Vondra wrote:
> On 7/9/25 19:23, Andres Freund wrote:
> > There's other things around this that could use some attention. It's not
> > hard
> > to see clock sweep be a bottleneck in concurrent workloads - partially due
> > to
> > the shared maintenance of
Hi,
On 2025-07-10 08:21:56 +, Bertrand Drouvot wrote:
> - Let's define a list of "cheap" and a list of "expensive" wait events
> - Change the code path to increment counters only for the "expensive" ones
> - Optimize the counter incrementation as much as possible
>
> Does that sound reasonabl
"David G. Johnston" writes:
> On Friday, July 11, 2025, Zhang Mingli wrote:
>> So, are both result sets technically correct given the absence of an ORDER
>> BY clause?
> The system is behaving within the requirements of the specification. The
> query itself is bugged code that the query author
On Fri, Jul 11, 2025 at 8:21 PM Nathan Bossart wrote:
>
> > Also just would like to confirm that the pg_dump_sort change will go in a
> > different patch.
>
> That's already been committed: http://postgr.es/c/fb6c860.
>
That's great. Thank you.
Hi,
Please find attached the latest memory context statistics monitoring patch.
It has been redesigned to address several issues highlighted in the thread
[1]
and [2].
Here are some key highlights of the new design:
- All DSA processing has been moved out of the CFI handler function. Now,
all th
Bernd Helmle writes:
> FYI, since this commit TAP test pg_test_timing/001_basic on my machine
> with de_DE.UTF8 locale keeps failing with:
> ...
> Of course this is because of the localized comma in 99,9900%
Ah. I had the idea that we forced C locale in TAP tests,
but evidently that's not happen
Hi Amit,
Here is a proposed solution to handle the problem of creating the logical
replication slot on standby after a switchover.
Thank you for your comments and help on this issue
Regards
Fabrice
diff --git a/src/backend/replication/logical/slotsync.c
b/src/backend/replication/logical/slotsync
On Fri, 11 Jul 2025 at 8:27 PM, Nathan Bossart
wrote:
> On Fri, Jul 11, 2025 at 08:43:05AM +0530, Dilip Kumar wrote:
> > Thanks now, looks good to me.
>
> Thanks for reviewing.
>
> > Additionally IMHO it would be good to add tests with FLUSH_UNLOGGED TRUE
> > and FLUSH_UNLOGGED FALSE as well, I h
On Fri, Jul 11, 2025 at 08:43:05AM +0530, Dilip Kumar wrote:
> Thanks now, looks good to me.
Thanks for reviewing.
> Additionally IMHO it would be good to add tests with FLUSH_UNLOGGED TRUE
> and FLUSH_UNLOGGED FALSE as well, I have added a simple 2 test for the
> same in attached file.
I'll add
On Fri, Jul 11, 2025 at 07:49:47PM +0530, Nitin Motiani wrote:
> Thanks. Looks good to me.
Thank you for reviewing.
> Also just would like to confirm that the pg_dump_sort change will go in a
> different patch.
That's already been committed: http://postgr.es/c/fb6c860.
--
nathan
Hi,
On 2025-07-11 14:03:42 +0300, Nikita Malakhov wrote:
> It's a pity I missed this thread when you developed the patch.
> I've developed a feature recently and discovered that SeqScan
> does not make use of scan keys, and there is a Tom Lane's
> comment regarding this:
> * Note that unlike Ind
Hi,
On 2025-07-11 11:22:36 +0900, Amit Langote wrote:
> On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> > On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > > Thanks for the patch.
> > >
> > > +/*
> > > + * Use pg_assume() for != NULL tests to make the compiler realize no
> > >
On Fri, Jul 11, 2025 at 3:12 AM Nathan Bossart
wrote:
> On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
> > - * pg_largeobject_metadata, after the dump is restored.
> > + * pg_largeobject_metadata, after the dump is restored.
> In versions
> > +
On 08/07/2025 2:51 pm, Amit Kapila wrote:
On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote:
There is well known Postgres problem that logical replication subscriber
can not caught-up with publisher just because LR changes are applied by
single worker and at publisher changes are made
On 11/7/2025 10:16, Amit Langote wrote:
Hi,
I’ve been experimenting with an optimization that reduces executor
overhead by avoiding unnecessary attribute deformation. Specifically,
if the executor knows which attributes are actually needed by a plan
node’s targetlist and qual, it can skip deform
On Friday, July 11, 2025, Zhang Mingli wrote:
>
> Referring to the SQL 2011 standard, it states that if ORDER BY is
> omitted, the order of rows in the partition is undefined.
> While using a window function without ORDER BY is valid, the resulting
> output seems unpredictable.
>
> So, are both r
> On 30 Jun 2025, at 16:34, Andrey Borodin wrote:
>
> Please find attached two new steps for amcheck:
> 1. A function to verify GiST integrity. This patch is in decent shape, simply
> rebased from previous year.
> 2. Support on pg_amcheck's side for this function. This patch did not receive
>
Hi,
The v3 patch attached. (Add some comment in commit msg)
--
Regards,
ChangAo Chen
v3-0001-Small-optimization-with-expanding-dynamic-hash-ta.patch
Description: Binary data
On Fri, Jul 11, 2025 at 12:22 PM Amit Langote wrote:
> Thanks, I see that you've thought this through and opted for the safe
> route of locking all possible partitions during planning, both for
> SELECT and INSERT.
>
> That seems like the only viable option today, given how the executor
> assumes
Hi Amit!
It's a pity I missed this thread when you developed the patch.
I've developed a feature recently and discovered that SeqScan
does not make use of scan keys, and there is a Tom Lane's
comment regarding this:
* Note that unlike IndexScan, SeqScan never use keys in heap_beginscan
* (and
Hi,
On Thu, 10 Jul 2025 at 20:12, Jacob Champion
wrote:
>
> On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz wrote:
> > Andres off-list mentioned that if we explicitly enable features for
> > *all* of the tasks, then none of the tasks will be testing the auto
> > feature option and I agree with
On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada wrote:
>
> On Wed, Jul 9, 2025 at 9:09 PM Amit Kapila wrote:
>
> >
> > > I think that even with retain_conflict_info = off, there is probably a
> > > point at which the subscriber can no longer keep up with the
> > > publisher. For example, if with
On 11/07/2025 10:51, Laurenz Albe wrote:
Good idea; done in the attached version 2 of the patch.
Thanks! Looks good. I have set the status of the Commitfest entry to
"Ready for Committer".
Kind regards,
Mircea Cadariu
Hi!
In case of out_of_memory, the ecpg_strdup function may return NULL.
Checks should be added in src/interfaces/ecpg/ecpglib/execute.c.
Patch attached.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--
Best regards,
Evgeniy Gorbanev
diff --git a/src/interfaces/ecpg/ecpglib/
On 11/07/2025 11:52 am, Amit Kapila wrote:
On Wed, Jul 9, 2025 at 12:08 AM Konstantin Knizhnik wrote:
On 08/07/2025 2:51 pm, Amit Kapila wrote:
On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik wrote:
It is possible to enforce parallel apply of short
transactions using `debug_logical_rep
Op 7/10/25 om 22:00 schreef Dmitry Mityugov:
When compiled with Assert() macro disabled, GCC 15 produces warnings
about possibly uninitialized variables in
src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
detail in this thread, in April 2025:
https://www.postgresql.org/
Hi,
I am reaching out to discuss the behavior of window functions in Postgres,
specifically regarding the use of the OVER() clause without an ORDER BY
specification.
In our recent tests, we observed that the results can be unstable.
For example, when executing the following query:
SELECT sum(u
Le 10.07.2025 00:14, Tom Lane a écrit :
Damien Clochard writes:
So this adds 5 new variants of the random() function:
random(min date, max date) returns date
random(min time, max time) returns time
random(min time, max time, zone text) returns timetz
random(min timestamp,
On Fri, 11 Jul 2025 at 17:16, Amit Langote wrote:
> Hi,
>
> I’ve been experimenting with an optimization that reduces executor
> overhead by avoiding unnecessary attribute deformation. Specifically,
> if the executor knows which attributes are actually needed by a plan
> node’s targetlist and qual
Am Dienstag, dem 08.07.2025 um 11:25 -0400 schrieb Tom Lane:
> Hannu Krosing writes:
> > On Mon, Jul 7, 2025 at 11:38 PM Tom Lane wrote:
> > > What do you think of instead specifying the limit as the maximum
> > > running-percentage to print, with a default of say 99.99%? That
> > > gives me res
[moving to pgsql-hackers]
On Thu, 2025-07-10 at 17:20 +0100, Mircea Cadariu wrote:
> I have only one suggestion for the patch. Consider adding a
> corresponding test in src/bin/scripts/t/100_vacuumdb.pl.
>
> Proposal (I used this to check the patch):
>
> $node->safe_psql('postgres',
>
Hi!
On Fri, Jun 27, 2025 at 8:34 PM Matthias van de Meent
wrote:
>
> Hi,
>
> Recently I had to debug an issue with VACUUM's truncate stage taking
> an AE lock for a long time, which caused an unpleasant outage due to
> blocked queries on a replica. That, and remembering a thread about
> this over
Hi
> The v2 patch maybe more clear:
> We can calc bucket just by hashvalue & high_mask when expanding table
because the if condition in calc_bucket() must be false.
I think you may add a comment to this path so that code reviewers can
clearly see your optimization.
Thanks
On Thu, Jul 10, 2025 at
Hi,
On Thu, Jul 10, 2025 at 04:34:34PM -0500, Sami Imseih wrote:
> Thanks for the feedback!
>
> > > Attached is a proof of concept that does not alter the
> > > LWLockRegisterTranche API. Instead, it detects when a registration is
> > > performed by a normal backend and stores the tranche name in
On Fri, 11 Jul 2025 at 16:31, Peter Smith wrote:
> Hi. Here is the latest patch set v12*
>
> Main differences are:
>
> Patch 0001 (core)
> - removed SizeOfIptrData macro, as reported by Tomas [1] and Japin [2]
>
> Patch 0002 (vci module)
> - Made fixes so the "ROS Control Worker" (for background W
Dear David,
Thank you very much for your feedback and clarification.
We now realize that the current immutability mechanism in PostgreSQL has been established for a long time, and changing it at this point would not only be difficult but also risk breaking backward compatibility.
We appreciate y
When compiled with Assert() macro disabled, GCC 15 produces warnings
about possibly uninitialized variables in
src/backend/utils/adt/jsonb_util.c module. This problem was discussed in
detail in this thread, in April 2025:
https://www.postgresql.org/message-id/988bf1bc-3f1f-99f3-bf98-222f1cd9d..
Hello Abhishek,
I have reviewed your patch after there was no response to my initial proposal
and nobody else wrote a review yet.
The patch is in the correct unified-diff format (apparently generated via git
format-patch). It applies cleanly to the current master branch. The patch does
not howeve
On Wed, Jul 9, 2025 at 4:11 PM vignesh C wrote:
>
> > 3)
> > SyncFetchRelationStates:
> > Earlier the name was FetchTableStates. If we really want to use the
> > 'Sync' keyword, we can name it FetchRelationSyncStates, as we are
> > fetching sync-status only. Thoughts?
>
> Instead of FetchRelatio
On Wed, Jul 9, 2025 at 12:08 AM Konstantin Knizhnik wrote:
>
> On 08/07/2025 2:51 pm, Amit Kapila wrote:
>
> On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik
> wrote:
>
> It is possible to enforce parallel apply of short
> transactions using `debug_logical_replication_streaming` but then
> pe
10.07.2025 18:57, Zhou, Zhiguo пишет:
>
>
> On 7/9/2025 3:56 PM, Yura Sokolov wrote:
>> 30.05.2025 14:30, Zhou, Zhiguo пишет:
>>> Hi Hackers,
>>>
>>> I am reaching out to solicit your insights and comments on this patch
>>> addressing a significant performance bottleneck in LWLock acquisition
>>>
On Thu, Jul 10, 2025 at 11:55 PM David E. Wheeler
wrote:
> On Jul 10, 2025, at 16:38, Florents Tselai
> wrote:
>
> > Why isn’t this sufficient?
> >
> > static uint64
> > pg_base64_encode_internal(const char *src, size_t len, char *dst, bool
> url)
> > {
> > const char *alphabet = url ? _base64ur
Hi,
I’ve been experimenting with an optimization that reduces executor
overhead by avoiding unnecessary attribute deformation. Specifically,
if the executor knows which attributes are actually needed by a plan
node’s targetlist and qual, it can skip deforming unused columns
entirely.
In a proof-o
On Tue, 8 Jul 2025 at 15:26, Aleksander Alekseev
wrote:
>
> The proposed function seems to do two things at a time - generating
> random values and transforming them into an array of desired
> dimensions. Generally we try to avoid such interfaces. Can you think
> of something like array_transform(
On Tue, 8 Jul 2025 at 09:51, Dean Rasheed wrote:
>
> Answering my own question, INSERT ... ON CONFLICT DO UPDATE does have
> the same problem as MERGE. To reproduce the error, all you need to do
> is create the unique index it needs *after* creating the publication
The other question is whether w
70 matches
Mail list logo
