On Thu, Sep 25, 2025 at 02:35:16PM -0400, Robert Haas wrote:
> On a related note, something a committer would need to do if they
> wanted to commit this patch is figure out who should be credited with
> writing it. I see that a number of different people have posted
> versions of the patch; it woul
On Thu, Oct 23, 2025 at 8:58 AM Peter Smith wrote:
>
> On Wed, Oct 22, 2025 at 8:28 PM Amit Kapila wrote:
> >
> > On Wed, Oct 22, 2025 at 2:40 PM shveta malik wrote:
> > >
> > > On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada
> > > wrote:
> > > >
> > >
> > > I want to discuss the create-publi
On Mon, 2025-10-20 at 07:41 -0400, David G. Johnston wrote:
> I question whether “parameter” is even the correct class to assign here
> and so would rather avoid the issue by not assigning a class.
Right. I have removed the vestiges from my failed attempt to improve
the "parameter" decorations.
On Thu, 23 Oct 2025 at 16:43, Richard Guo wrote:
> How about using the following wording in the commit message?
>
> "
> The previous logic in query_is_distinct_for() was incomplete because
> the check was insufficiently thorough and could return false when it
> should have returned true.
> "
"it
On Thu, Oct 23, 2025 at 12:26 AM Xuneng Zhou wrote:
> > I've created a patch adding your suggested comments (attached).
> > Since this is a follow-up to commit 883a95646a8, which was recently applied
> > and backpatched to all supported branches, I think we should backpatch
> > this one as well. T
Michael Paquier writes:
> On Thu, Oct 23, 2025 at 11:18:09AM +0800, Quan Zongliang wrote:
>> Improve the completeness of the code.
> errfinish() calls MemoryContextReset() on ErrorContext so as any leaks
> like the one you are cleaning up are taken care of. Still, what you
> are suggesting is si
On Wed, Oct 22, 2025 at 5:32 PM Tim Waizenegger
wrote:
>
> updated patch is attached
>
I’ve done some refactoring, hope it’s now more intuitive to you.
Since a domain’s base type can itself be another domain, it’s better to use
appendStringInfo(&buf, "CREATE DOMAIN %s AS %s",
On Thu, Oct 23, 2025 at 11:18:09AM +0800, Quan Zongliang wrote:
> On 9/19/25 7:16 PM, Aleksander Alekseev wrote:
>> Currently waitonlock_error_callback() allocates memory in ErrorContext
>> and doesn't explicitly free it. Valgrind is not happy about it and
>> generates multiple reports like this:
>
On Thu, Oct 9, 2025 at 10:53 AM Amit Kapila wrote:
>
> On Wed, Oct 8, 2025 at 9:05 PM Fabrice Chapuis
> wrote:
> >
> > As Ashutosh suggests I will go more for the backpatching approach because
> > the synchronized_standby_slots parameter impacts the last 2 major versions
> > and this problem i
On Thu, Oct 23, 2025 at 12:07 PM David Rowley wrote:
> Or if it's a case of it returning false when it could have returned
> true, then maybe the commit message should make that clear. I'm unable
> to tell from reading it. Something like; "The previous logic in
> query_is_distinct_for() was incomp
On Wed, Oct 22, 2025 at 03:24:11PM -0500, Sami Imseih wrote:
> I'd like to propose $SUBJECT to serialize additional per-entry data beyond
> the standard statistics entries. Currently, custom statistics kinds can store
> their standard entry data in the main "pgstat.stat" file, but there is no
> mec
On Wed, Oct 22, 2025 at 8:28 PM Amit Kapila wrote:
>
> On Wed, Oct 22, 2025 at 2:40 PM shveta malik wrote:
> >
> > On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada
> > wrote:
> > >
> >
> > I want to discuss the create-publication case, which currently gives
> > this warning:
> >
> > postgres=#
On 9/19/25 7:16 PM, Aleksander Alekseev wrote:
Hi,
Currently waitonlock_error_callback() allocates memory in ErrorContext
and doesn't explicitly free it. Valgrind is not happy about it and
generates multiple reports like this:
```
2,048 bytes in 2 blocks are definitely lost in loss record 1,
On Thu, 23 Oct 2025 at 15:59, David Rowley wrote:
> > No backpatch as this could result in plan changes.
>
> If this is broken then it'll need to be backpatched as if that
> function returns true when it should return false, then you could have
> LEFT JOINs being removed when they shouldn't or joi
On Thu, 23 Oct 2025 at 15:45, Richard Guo wrote:
>
> On Wed, Oct 22, 2025 at 6:25 PM Richard Guo wrote:
> > Attached is a patch along the lines of option #2. The LCOV report
> > indicates that there is currently no test coverage for the "else if
> > (query->groupingSets)" branch in query_is_dist
On Wed, Oct 22, 2025 at 6:25 PM Richard Guo wrote:
> Attached is a patch along the lines of option #2. The LCOV report
> indicates that there is currently no test coverage for the "else if
> (query->groupingSets)" branch in query_is_distinct_for(). This patch
> also adds test cases to cover that
Hi Alvora,
I have reviewed and tested the patch, and got a few comments.
> On Oct 21, 2025, at 16:05, Álvaro Herrera wrote:
>
> This was lacking rebase after the func.sgml changes. Here it is again.
> I have not reviewed it.
>
> --
> Álvaro Herrera 48°01'N 7°57'E — https://ww
[email protected] writes:
> I'd like to bring attention to a metadata visibility issue when multiple
> schemas contain sequences with identical names, and a table column references
> one of them via nextval(). Currently, there appears to be no reliable way to
> determine whi
Hi hackers,
I'd like to bring attention to a metadata visibility issue when multiple
schemas contain sequences with identical names, and a table column references
one of them via nextval(). Currently, there appears to be no reliable way to
determine which schema's sequence is actually reference
>> On Mon, 20 Oct 2025 at 16:59, Tatsuo Ishii wrote:
>>>
>>> > A very trivial commit:
>>> >
>>> > ```
>>> > + else
>>> > +
>>> > + /*
>>> > + * For other cases we have no idea what position of row
>>> > callers would
>>> > + * fetch next time. Also for re
I have realized that there's an oversight in my recent commit
c6f7f11d8, which so far from preventing edge-case leaks as intended,
actually introduces a memory leak in the normal error-catching path.
The leakage is easy to see if you extract the
catch_python_unique_violation() test case from plpyth
> On 9/16/25 8:18 AM, Matheus Alcantara wrote:
>
>> Any opinions on this?
>> [1]
>> https://www.postgresql.org/message-id/CAKFQuwbR1Fzr8yRuMW%3DN1UMA1cTpFcqZe9bW_-ZF8%3DBa2Ud2%3Dw%40mail.gmail.com
> Just as the discussion here. Adding extension location is a good idea.
+1. I like the ideal.
On Thu, Oct 23, 2025 at 08:46:27AM +0900, Michael Paquier wrote:
> I'd prefer the new format. One killer pushing in favor of the new
> format that you are making upthread in favor of is that it makes much
> easier the viewing, editing and injecting of these stats.
This is missing an "argument", a
On Mon, Oct 20, 2025 at 11:13 PM Xuneng Zhou wrote:
>
> Hi,
>
> Thanks for looking into this.
>
> On Tue, Oct 21, 2025 at 1:05 PM Kirill Reshke wrote:
> >
> > On Tue, 21 Oct 2025 at 04:31, Michael Paquier wrote:
> > >
> > > On Sat, Oct 18, 2025 at 01:59:40PM +0500, Kirill Reshke wrote:
> > > > I
On 9/16/25 8:18 AM, Matheus Alcantara wrote:
Any opinions on this?
[1]
https://www.postgresql.org/message-id/CAKFQuwbR1Fzr8yRuMW%3DN1UMA1cTpFcqZe9bW_-ZF8%3DBa2Ud2%3Dw%40mail.gmail.com
Just as the discussion here. Adding extension location is a good idea.
Suppose there is an amcheck 1.5 lo
On Wed, Oct 22, 2025 at 03:57:15PM -0500, Sami Imseih wrote:
> OK, fair enough. I don't have enough compelling use-cases to push
> back harder on this. Initially, my focus was on the fact that unlike
> built-in stats, custom stats may not have a registered kind and
> disposing of all the stats in t
On Tue Oct 21, 2025 at 11:25 AM -03, Matheus Alcantara wrote:
>>> Lastly, I don't know if we should change the EXPLAIN(ANALYZE, VERBOSE)
>>> output for batch inserts that use the COPY to mention that we are
>>> sending the COPY command to the remote server. I guess so?
>>>
>>
>> Good point. We defi
On Wed, Oct 22, 2025 at 02:55:31PM +0300, Corey Huinker wrote:
>> Do you have some numbers regarding the increase in size this generates
>> for the catalogs?
>
> Sorry, I don't understand. There shouldn't be any increase inside the
> catalogs as the internal storage of the datatypes hasn't changed
On Wed, Oct 22, 2025 at 4:10 PM Michael Paquier wrote:
>
> On Wed, Oct 22, 2025 at 03:25:39PM -0700, Masahiko Sawada wrote:
> > I noticed that 048_vacuum_horizon_floor.pl is missing the copyright
> > notice. I've attached a patch to add it.
>
> LGTM.
Thanks. It seems an oversight in commit 303ba0
I'm not sure what that comment would say.
Should there be such a thing as a maximum meson version that postgres supports?
Matt
From: Daniel Gustafsson
Sent: Wednesday, October 22, 2025 6:30 PM
To: Matt Smith (matts3)
Cc: PostgreSQL Hackers
Subject: Re: Meson in
I'm not sure if it's expected because of some recent infrastructure
changes, but cloning Postgres repo with the following commands fails.
# Using command from Postgres docs at
# https://www.postgresql.org/docs/current/git.html
$ git clone git://git.postgresql.org/git/postgresql.git
Cloning into 'p
On Wed, Oct 22, 2025 at 03:25:39PM -0700, Masahiko Sawada wrote:
> I noticed that 048_vacuum_horizon_floor.pl is missing the copyright
> notice. I've attached a patch to add it.
LGTM.
--
Michael
signature.asc
Description: PGP signature
>
> doc said trigger name can not be schema-qualified,
>>> we can not do:
>>> CREATE TRIGGER public.modified_a BEFORE UPDATE OF a ON main_table
>>> FOR EACH ROW WHEN (OLD.a <> NEW.a) EXECUTE PROCEDURE
>>> trigger_func('modified_a');
>>
>>
>>
>>> + nameList = textToQualifiedNameList(trgName);
>>>
>>
Hi,
I noticed that 048_vacuum_horizon_floor.pl is missing the copyright
notice. I've attached a patch to add it.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
add_copyright.patch
Description: Binary data
Hi Jian
doc said trigger name can not be schema-qualified,
>> we can not do:
>> CREATE TRIGGER public.modified_a BEFORE UPDATE OF a ON main_table
>> FOR EACH ROW WHEN (OLD.a <> NEW.a) EXECUTE PROCEDURE
>> trigger_func('modified_a');
>
>
>
>> + nameList = textToQualifiedNameList(trgName);
>>
>>
I a
On Tue, Oct 21, 2025 at 3:52 PM Peter Smith wrote:
>
> Hi Sawada-San.
>
> I reviewed the test code of patch v19; below are some minor comments.
>
> ==
>
> 1.
> +# Initialize the primary server with wal_level = 'replica'.
> +my $primary = PostgreSQL::Test::Cluster->new('primary');
> +$primary->
On Mon, Oct 20, 2025 at 10:28 PM Peter Smith wrote:
>
> Hi Sawada-San.
>
> Here are some mostly cosmetic review comments for patch v19 (excluding
> test code).
Thank you for reviewing the patch!
>
> ==
> doc/src/sgml/logicaldecoding.sgml
>
> 1.
> +
> + If either condition is met, the
On Wed, Oct 22, 2025 at 11:51 PM Andres Freund wrote:
> Have you figured out if the LLVM bug is specific to riscv or is more general?
> Afaict most of the MachineSink stuff mentioned in the llvm bug is generic, not
> arch specific. But I'd be surprised if such a problem in a more widely used
> arc
On Wed, Oct 22, 2025 at 05:16:54PM -0400, Tom Lane wrote:
> +1 for changing, but -1 for back-patching. Unless you're itching
> for reasons to update .abi-compliance-history. But if there's no
> live bug, that seems like make-work.
Yeah, makes sense. Committed, thanks for looking.
--
nathan
On Wed, Oct 22, 2025 at 4:06 AM shveta malik wrote:
>
> On Wed, Oct 22, 2025 at 2:58 PM Amit Kapila wrote:
> >
> > On Wed, Oct 22, 2025 at 2:40 PM shveta malik wrote:
> > >
> > > On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada
> > > wrote:
> > > >
> > >
> > > I want to discuss the create-publ
Nathan Bossart writes:
> I noticed that a couple of the functions added by commit 34694ec use
> "int16" instead of "uint16" for the infomask parameter. I don't think
> there are any live bugs here, but IMHO we should at least fix this for v19
> to help prevent future problems.
> Assuming there i
Hello Andres,
17.10.2025 08:21, Fujii Masao wrote:
On Fri, Oct 17, 2025 at 8:32 AM Michael Paquier wrote:
On Thu, Oct 16, 2025 at 10:00:00PM +0300, Alexander Lakhin wrote:
I collected all of such failures here:
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#check-pg_upgrade_fai
> On Tue, Oct 21, 2025 at 01:26:30PM -0500, Sami Imseih wrote:
> > Hmm, since the pgstat.stat file is managed by core and not by the
> > extension, I think this should be handled semi-automatically by
> > pgstats. Even with the checks you mention above, validating that we
> > are indeed loading the
Hi,
I'd like to propose $SUBJECT to serialize additional per-entry data beyond
the standard statistics entries. Currently, custom statistics kinds can store
their standard entry data in the main "pgstat.stat" file, but there is no
mechanism for extensions to persist extra data stored in the entry.
I noticed that a couple of the functions added by commit 34694ec use
"int16" instead of "uint16" for the infomask parameter. I don't think
there are any live bugs here, but IMHO we should at least fix this for v19
to help prevent future problems.
Assuming there is agreement on this change, any th
On Thu, Oct 23, 2025 at 08:34:49AM +1300, David Rowley wrote:
> On Thu, 23 Oct 2025 at 07:58, Nathan Bossart wrote:
>> I'm imagining something a bit like the following:
>>
>> select xidage "age(relfrozenxid)",
>> power(1.001, xidage::float8 / (select min_val
>> from pg_settings where n
On Thu, 23 Oct 2025 at 07:58, Nathan Bossart wrote:
> > That's a good point. I wonder if we should try to make the wraparound
> > score independent of the *_freeze_max_age parameters (once the table age
> > surpasses said parameters). Else, different settings will greatly impact
> > how aggressi
On Wed, Oct 22, 2025 at 03:33:37PM +0300, Nazir Bilal Yavuz wrote:
> On Tue, 21 Oct 2025 at 21:40, Nathan Bossart wrote:
>> I wonder if we could mitigate the regression further by spacing out the
>> checks a bit more. It could be worth comparing a variety of values to
>> identify what works best
On Wed, Oct 22, 2025 at 01:40:11PM -0500, Nathan Bossart wrote:
> On Wed, Oct 22, 2025 at 09:07:33AM +1300, David Rowley wrote:
>> However, just thinking of non-standard setting... I do wonder if it'll
>> be aggressive enough if someone did something like raise the
>> *freeze_max_age to 1 billion (
Hi! Thank you for your review.
Im posting new version of 0001 patch of series
On Tue, 22 Jul 2025 at 15:47, Arseniy Mukhin
wrote:
>
> Hi, Andrey!
>
> Thank you for working on this! There is a long history of the patch, I
> hope it will be committed soon!)
>
> On Fri, Jul 11, 2025 at 3:39 PM Andre
>> The get_formatted_string function is needed. Instead of using multiple if
> statements for the pretty flag, it’s better to have a generic function.
> This will be useful if the pretty-format DDL implementation is accepted by
> the community, as it can be reused by other pg_get__ddl() DDL
> funct
On Wed, Oct 22, 2025 at 09:07:33AM +1300, David Rowley wrote:
> However, just thinking of non-standard setting... I do wonder if it'll
> be aggressive enough if someone did something like raise the
> *freeze_max_age to 1 billion (it's certainly common that people raise
> this). With a 1.6 billion v
On Wed, Oct 22, 2025 at 04:20:01PM +0300, Aleksander Alekseev wrote:
> Here is the updated patch.
Committed.
--
nathan
On Wed Oct 22, 2025 at 12:49 PM -03, Álvaro Herrera wrote:
> On 2025-Oct-22, Matheus Alcantara wrote:
>
>> I'm wondering if the 002_aborted_tx_notifies.pl is still needed with
>> this architecture being used. I think that it's not, but perhaps is a
>> good test to keep it?
>
> I'd rather have tests
Hi Jian,
> doc said trigger name can not be schema-qualified,
> we can not do:
> CREATE TRIGGER public.modified_a BEFORE UPDATE OF a ON main_table
> FOR EACH ROW WHEN (OLD.a <> NEW.a) EXECUTE PROCEDURE
> trigger_func('modified_a');
That's correct. The function wouldn't produce that output thoug
On Wed, Oct 22, 2025 at 11:33:20AM -0500, Nathan Bossart wrote:
> On Wed, Oct 22, 2025 at 10:40:50AM -0400, Tom Lane wrote:
>> so I guess we need to add 24f6c1bd4 to that history.
>
> Yup. Will do.
Ope, looks like you took care of it already, thanks.
--
nathan
On Wed, Oct 22, 2025 at 10:40:50AM -0400, Tom Lane wrote:
> so I guess we need to add 24f6c1bd4 to that history.
Yup. Will do.
--
nathan
Hi hackers.
We see the following error reported by amcheck (I have added dump of
opaque) when it interleaves with autovacuum and cancel pt:
ERROR: mismatch between parent key and child high key in index
"pg_attribute_relid_attnam_index"
DETAIL: Target block=274, target opaque->flags=0, chi
[ blast-from-the-past department ]
Robert Haas writes:
> On Thu, Dec 1, 2016 at 6:33 AM, Thomas Munro
> wrote:
>> Please find attached dsa-v8.patch, and also a small test module for
>> running random allocate/free exercises and dumping the internal
>> allocator state.
> OK, I've committed the m
[ seizing on this old commit as being most closely related to the issue ]
Thomas Munro writes:
> On Tue, Jul 16, 2024 at 1:52 PM Noah Misch wrote:
>> On Mon, Jul 15, 2024 at 03:26:32PM +1200, Thomas Munro wrote:
>> That's reasonable. radixtree already forbids mutations concurrent with
>> iterat
Jacob Champion writes:
> (I don't know the answer to this question, but I will note that clang
> (15.0.7) does not seem to make this mistake on my machine, and reports
> a call count of zero for the `return` on line 1495. Looking at the
> disassembly, it seems to add more instrumentation points th
On 2025-Oct-22, Matheus Alcantara wrote:
> I'm wondering if the 002_aborted_tx_notifies.pl is still needed with
> this architecture being used. I think that it's not, but perhaps is a
> good test to keep it?
I'd rather have tests than not, but I'd think it needs to be behind
PG_TEST_EXTRA because
On Tue, Oct 21, 2025 at 11:11 PM Hayato Kuroda (Fujitsu)
wrote:
> Per above, I could consider in pguotput.c., line 1495 was actually executed
> but
> 1503 was counted when it reached line 1494. Another question is why one of the
> branch was reported as 100% and another one was 0%. Is it just bec
Hi,
On Wed, Oct 22, 2025 at 10:45 PM Fujii Masao wrote:
>
> On Wed, Oct 22, 2025 at 4:49 PM Xuneng Zhou wrote:
> > How about something like:
> >
> > /*
> > * Overflow entries for read heads that collide with the write head.
> > *
> > * When the cyclic buffer fills (write head is about to coll
On Wed Oct 22, 2025 at 1:31 AM -03, Masahiko Sawada wrote:
> On Tue, Oct 21, 2025 at 4:16 PM Matheus Alcantara
>> > I think adding a new GUC would be overkill for this fix. As for
>> > dropping old notifications from the queue, we probably don't need to
>> > make it configurable - we could simply d
On Wed, Oct 22, 2025 at 4:49 PM Xuneng Zhou wrote:
> How about something like:
>
> /*
> * Overflow entries for read heads that collide with the write head.
> *
> * When the cyclic buffer fills (write head is about to collide with a read
> * head), we save that read head's current sample here a
Hi,
On Wed, Oct 22, 2025 at 02:51:31PM +0900, Michael Paquier wrote:
>
> A first part here is something that Bertrand Drouvot has been working
> on: being able to rebuild the table stats during WAL replay requires
> us to move the stats to be relfilenode-based, so as the startup could
> know wher
Nathan Bossart writes:
> Great. All back-branches now have an .abi-compliance-history file.
Looks like we're good on v13-v16, but v17 is complaining
1 Removed function:
[D] 'function bool check_max_slot_wal_keep_size(int*, void**, GucSource)'
{check_max_slot_wal_keep_size}
so I guess we
.
On Tue, Oct 21, 2025 at 2:10 PM Pavel Stehule wrote:
> út 21. 10. 2025 v 6:07 odesílatel Amit Langote
> napsal:
>>
>> On Thu, Apr 3, 2025 at 7:19 PM Amit Langote wrote:
>> > On Fri, Dec 20, 2024 at 1:23 PM Amit Langote
>> > wrote:
>> > > We discussed $subject at [1] and [2] and I'd like to
Hi,
On 2025-09-01 12:36:24 +0200, David Geier wrote:
> > Open questions I have:
> > - Could we rely on checking whether the TSC timesource is invariant (via
> > CPUID), instead of relying on Linux choosing it as a clocksource?
>
> Why do you want to do that? Are you concerned that Linux might pic
On Wed, Oct 22, 2025 at 12:52 PM Fujii Masao wrote:
> So let's push the current patch, including only the cosmetic indentation
> changes suggested by Hayato-san.
I've pushed the patch. Thanks!
Attached is the rebased version of the patch I shared earlier, which adds
GUC_check_errmsg_internal(),
On Wed, Oct 22, 2025 at 12:51 PM jian he
wrote:
> On Thu, Oct 16, 2025 at 8:51 PM Akshay Joshi
> wrote:
> >
> > Please find attached the v3 patch, which resolves all compilation errors
> and warnings.
> >
>
> drop table if exists t, ts, ts1;
> create table t(a int);
> CREATE POLICY p0 ON t FOR A
Hi Nathan,
> > + {
> > + char *nsp =
> > get_namespace_name(RelationGetNamespace(tempRel));
> > + char *temprelname = RelationGetRelationName(tempRel);
> > + char *diffrelname = psprintf("%s_%d", temprelname, 2);
>
> I assume the intent of
On Tue, Oct 21, 2025 at 2:39 PM Chao Li wrote:
>
>
> > On Oct 16, 2025, at 20:50, Akshay Joshi
> wrote:
> >
> > Please find attached the v3 patch, which resolves all compilation errors
> and warnings.
> >
> > On Thu, Oct 16, 2025 at 6:06 PM Philip Alger wrote:
> > Hi Akshay,
> >
> >
> > As for
On 2025-10-22 14:28:24 +0300, Lukas Fittl wrote:
> On Tue, Sep 9, 2025 at 10:35 PM Lukas Fittl wrote:
>
> > Attached an updated patch set that addresses the feedback, and also adds
> > the complete removal of the global pgBufferUsage variable in later patches
> > (0005-0007), to avoid counting bot
On Wed, Oct 1, 2025 at 6:10 PM Robert Haas wrote:
> On Tue, Sep 30, 2025 at 1:24 PM Srinath Reddy Sadipiralla
> wrote:
> > Can you please once confirm this, did you mean that this is not even an
> actual problem to fix or only this patch's logic which I provided does not
> make sense?, because i
Hi,
On Tue, 21 Oct 2025 at 21:40, Nathan Bossart wrote:
>
> On Tue, Oct 21, 2025 at 12:09:27AM +0300, Nazir Bilal Yavuz wrote:
> > I think the problem is deciding how many lines to process before
> > deciding for the rest. 1000 lines could work for the small sized data
> > but it might not work f
Hi all,
I tried to fix a bug in PostgreSQL where ALTER TABLE ... DROP EXPRESSION
fails on multi-level inheritance hierarchies.
Bug:
When a parent table has a generated column and child/grandchild tables
inherit from it, executing:
ALTER TABLE parent ALTER COLUMN d DROP EXPRESSION;
ERROR: ALTER
> On 22 Oct 2025, at 11:24, Jelte Fennema-Nio wrote:
>
> On Wed, 22 Oct 2025 at 10:49, Daniel Gustafsson wrote:
>> Orange cross and Red cross are probably too similar to be easily discernible
>> for people with color blindness. Since the patch is technically "green",
>> what
>> do you think ab
On Wed, Oct 22, 2025 at 12:27 PM Chao Li wrote:
>
> Hi Tim,
>
> Thanks for working on this. I haven’t finished reviewing the entire patch.
> But I got a quick question:
>
> While reviewing a similar patch of pg_get_policy_ddl(), it take the last
> parameter as a pretty flag. I wonder why pg_get_
>
> The functions exposed in 0003 should be renamed to match more with the
> style of the rest, aka it is a bit hard to figure out what they do at
> first sight. Presumably, these should be prefixed with some
> "statext_", except text_to_stavalues() which could still be named the
> same.
>
That p
On Tue, Sep 9, 2025 at 10:35 PM Lukas Fittl wrote:
> Attached an updated patch set that addresses the feedback, and also adds
> the complete removal of the global pgBufferUsage variable in later patches
> (0005-0007), to avoid counting both the stack and the variable.
>
See attached the same pat
On Wed, Oct 22, 2025 at 2:58 PM Amit Kapila wrote:
>
> On Wed, Oct 22, 2025 at 2:40 PM shveta malik wrote:
> >
> > On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada
> > wrote:
> > >
> >
> > I want to discuss the create-publication case, which currently gives
> > this warning:
> >
> > postgres=#
Hi,
On 2025-10-20 13:05:53 +1100, Thomas Munro wrote:
> Updating the list with some progress: Alexander narrowed it down to
> pgaio_io_wait() being inlined into pgaio_io_was_recycled(). It seems
> to have some instructions in the wrong order, and that can be
> reproduced standalone, so I've aske
Hi Tim,
Thanks for working on this. I haven’t finished reviewing the entire patch. But
I got a quick question:
> On Oct 22, 2025, at 17:32, Tim Waizenegger
> wrote:
>
> updated patch is attached
>
> ---
> Best regards,
> Florin Irion
> Tim Waizenegger
>
> EDB (EnterpriseDB)
>
```
+/*
+ *
On Thu, Oct 16, 2025 at 1:05 PM jian he wrote:
>
> On Thu, Oct 16, 2025 at 5:17 PM Tim Waizenegger
> wrote:
> >
> > Hi all,
> >
> > Following the recent "Retail DDL" discussion [1], we're submitting another
> > implementation: pg_get_domain_ddl().
> >
>
> select pg_get_domain_ddl(-1);
> will caus
On Wed, Oct 22, 2025 at 2:40 PM shveta malik wrote:
>
> On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada
> wrote:
> >
>
> I want to discuss the create-publication case, which currently gives
> this warning:
>
> postgres=# create publication pub1 for all tables;
> WARNING: logical decoding shoul
While working on the fix for the push-down-HAVING optimization, I
noticed $subject.
query_is_distinct_for() is intended to determine whether a query never
returns duplicates of the specified columns. For a query using
grouping sets, if there are no grouping expressions, we know there are
no non-e
On Wed, 22 Oct 2025 at 10:49, Daniel Gustafsson wrote:
> Orange cross and Red cross are probably too similar to be easily discernible
> for people with color blindness. Since the patch is technically "green", what
> do you think about just changing the checkmark on such patches?
Good point. I ch
On Fri, Oct 17, 2025 at 11:09 PM Masahiko Sawada wrote:
>
> On Fri, Oct 17, 2025 at 5:07 AM shveta malik wrote:
> >
> > On Fri, Oct 17, 2025 at 12:47 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Oct 16, 2025 at 9:07 PM shveta malik
> > > wrote:
> > > >
> > > > On Fri, Oct 17, 2025 at 8:5
Hi,
On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
> Benjamin Leff writes:
> >> I believe the prevailing opinion was that the amount
> >> of time saved by not building all of PG didn't justify the maintenance
> >> effort to keep the build scripts working for that case
>
> > IMO, it’s not just abo
> On 1 Sep 2025, at 07:27, Peter Eisentraut wrote:
> I suggest that instead of adding the context to the Port structure, make a
> separate context struct for this purpose, for example:
Fair enough, done in the attached.
> This seems like an extremely inconvenient solution, as can be seen by th
>
>
> ```
> % make check
> …
> 1..230
> # All 230 tests passed.
> ```
>
Rebased v2 attached.
Best regards,
Chao Li (Evan)
-
HighGo Software Co., Ltd.
https://www.highgo.com/
v2-0001-Alow-ALTER-COLUMN-TYPE-when-dependent-generated-c.patch
Description: Binary data
> On 22 Oct 2025, at 10:41, Jelte Fennema-Nio wrote:
> I updated the commitfest
> app to now show it with an orange cross instead of a red one (see
> attached png).
Orange cross and Red cross are probably too similar to be easily discernible
for people with color blindness. Since the patch is t
On Mon, Oct 20, 2025 at 11:41 AM Bertrand Drouvot
wrote:
>
> On Fri, Oct 17, 2025 at 03:08:07PM -0700, Masahiko Sawada wrote:
> > On Fri, Oct 17, 2025 at 12:18 AM Bertrand Drouvot
> > wrote:
>
> > > do you think that's also safe to not
> > > invalidate the slots for effective_xmin and catalog_eff
On Wed, Oct 22, 2025 at 05:04:58PM +0900, Shinya Kato wrote:
> The 0001 patch adds these columns to pg_stat_wal. The 0002 and 0003
> patches add this information to EXPLAIN (WAL) and pg_stat_statements,
> respectively. I don't think these additions (0002 and 0003) are
> mandatory, so I suggest we f
On Tue, 21 Oct 2025 at 16:49, Jelte Fennema-Nio wrote:
> By having it be a separate job I can easily make the
> cfbot and commitfest app report it as "yellow" instead of "red" if
> this job fails.
I set "allow_failures: true" in the cirrus task, so that a formatting
failure won't show the whole b
Dear Sawada-san,
Thanks for updating the patch. Here are comments for v19.
I spent sometime to find race condition but nothing found. Below were for test
code.
```
# Copyright (c) 2024-2025, PostgreSQL Global Development Group
```
2024 can be removed.
```
# Create a temporary logical slot and
On Sun, Oct 19, 2025 at 5:35 AM Philip Alger wrote:
>
> Attached is v7. Moved the `initStringInfo` as suggested and reran tests.
>
hi.
https://www.postgresql.org/docs/current/sql-createtrigger.html
the parameter section:
The name to give the new trigger. This must be distinct from the name o
Hi hackers,
I am proposing a patch that adds wal_fpi_bytes_[un]compressed columns
to pg_stat_wal. These columns help us calculate WAL FPI (full page
image) compression rates, confirm the usefulness of wal_compression
and determine which compression algorithms are most effective.
Currently, we mus
1 - 100 of 105 matches
Mail list logo
