On Thu, Sep 18, 2025 at 4:07 PM vignesh C wrote:
>
> Thanks for the comments, these are handled in the attached patch.
>
Please find a few comments:
patch005:
1)
GetSubscriptionRelations:
+ /* Skip sequences if they were not requested */
+ if (!get_sequences && (relkind == RELKIND_SEQUENCE))
+
On Thu, Sep 18, 2025 at 5:23 AM Peter Smith wrote:
>
> Hi Shubham,
>
> Here are some v9 review comments.
>
> ==
> doc/src/sgml/ref/pg_createsubscriber.sgml
>
> --clean:
>
> 1.
> +
> + When publications are reused, they will not be dropped during
> cleanup
> + operat
Hi Fujii-san,
Thank you very much for taking care of this patch.
I just updated the patch, see attached v2. In v2, I removed "tid" from the
comment of heap_lock_tuple(), and I found a couple of more occurrences of
"relation"=>"rel" in tableam.h.
Best regards,
Chao Li (Evan)
-
On Mon, Sep 22, 2025 at 8:58 AM shveta malik wrote:
>
> On Fri, Sep 19, 2025 at 7:29 PM Ashutosh Sharma wrote:
> >
> > On Fri, Sep 19, 2025 at 3:04 PM shveta malik wrote:
> > >
> > > On Thu, Sep 18, 2025 at 5:20 PM Ashutosh Sharma
> > > wrote:
> > > >
> > > > Hi Ajin,
> > > >
> > > > On Thu, S
Hi,
@@ -646,7 +670,11 @@ synchronize_one_slot(RemoteSlot *remote_slot, Oid
remote_dbid)
remote_slot->name,
LSN_FORMAT_ARGS(latestFlushPtr)));
- return false;
+ /* If slot is present on the local, update the slot sync skip stats */
+ if ((slot = SearchNamedReplicationSlot(remote_slot->na
Hi Nazir,
Thanks for the review.
Hi Michael,
Thanks.
--
Thanks,
Oreo
From: Michael Paquier
Sent: Monday, September 22, 2025 06:18
To: Nazir Bilal Yavuz
Cc: Oreo Yang; [email protected]
Subject: Re: Meson0.57.2 setup failed with option -Duuid=ossp
On F
I quickly created a Python script and captured one more in
rewrite/rowsecurity.c. The file put filename reference in a different
format than other files:
```
diff --git a/src/backend/rewrite/rowsecurity.c
b/src/backend/rewrite/rowsecurity.c
index 4dad384d04d..3d6b6ba177b 100644
--- a/src/backend/r
On Fri, Sep 19, 2025 at 10:49 PM Masahiko Sawada wrote:
>
> On Fri, Sep 19, 2025 at 7:45 AM Ashutosh Bapat
> wrote:
> >
> > On Fri, Sep 12, 2025 at 2:26 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Fri, Sep 12, 2025 at 9:38 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > One thing related t
Looks like patch files need rebase.
> On Sep 20, 2025, at 04:40, Alexandra Wang
> wrote:
>
> Hi there,
>
> I've attached v20. It has the following changes:
>
> 1. New 0001: It adds test coverage for single-argument functions and
> casting for jsonb expressions. This ensures that the relevant
On Fri, Sep 19, 2025 at 7:29 PM Ashutosh Sharma wrote:
>
> On Fri, Sep 19, 2025 at 3:04 PM shveta malik wrote:
> >
> > On Thu, Sep 18, 2025 at 5:20 PM Ashutosh Sharma
> > wrote:
> > >
> > > Hi Ajin,
> > >
> > > On Thu, Sep 18, 2025 at 4:16 PM Ajin Cherian wrote:
> > > >
> > > > On Fri, Sep 12,
On Mon, 22 Sept 2025 at 11:56, Richard Guo wrote:
>
> On Sun, Sep 21, 2025 at 11:54 PM Steve Lau wrote:
> > Found a tiny incorrect comment of RangeTblEntry, field "alias" is actually
> > above "join_using_alias", so the code comment could be updated to reflect
> > the current field order:
> >
>
On Sat, Sep 20, 2025 at 9:58 PM Rintaro Ikeda
wrote:
> The points you both raise make sense to me.
> Changing the macro name is not important for the purpose of the patch, so I
> now
> feel it would be reasonable to drop patch 0002.
Thanks for your thoughts! So let's focus on the 0001 patch for
On Sat, Sep 20, 2025 at 12:21 AM Yugo Nagata wrote:
> > While testing, I found that running pgbench with --continue-on-error and
> > pipeline mode triggers the following assertion failure. Could this be
> > a bug in the patch?
> >
> > ---
> > $ cat p
I just upgraded to libxml2 2.15.0 and now the docs no longer validate
with the following error when running make html:
/usr/bin/xmllint --nonet --path . --path . --output postgres-full.xml
--noent --valid postgres.sgml
ref/pg_combinebackup.sgml:317: validity error : standalone:
n
On Mon, 22 Sept 2025 at 12:57, Richard Guo wrote:
>
> On Mon, Sep 22, 2025 at 9:53 AM David Rowley wrote:
> > I was just working on a script to find others and it highlighted a
> > bunch more. Do you still want to do this one, or should I take them
> > all in one fell swoop?
>
> Makes sense to ha
On 9/19/25 11:08 AM, jian he wrote:
hi.
with commit like:
https://git.postgresql.org/cgit/postgresql.git/commit/?id=78ee60ed84bb3a1cf0b6bd9a715dcbcf252a90f5
we can make a url link that points directly to a specific subsection
of the document.
for example:
https://www.postgresql.org/docs/deve
On Mon, Sep 22, 2025 at 9:53 AM David Rowley wrote:
> On Mon, 22 Sept 2025 at 11:59, Richard Guo wrote:
> > On Mon, Sep 22, 2025 at 8:10 AM Chao Li wrote:
> > > When gin_tuple.h was introduced by commit 8492feb[1], the file header
> > > comment incorrectly referred to gin.h. Update the comment
On Mon, 22 Sept 2025 at 11:59, Richard Guo wrote:
>
> On Mon, Sep 22, 2025 at 8:10 AM Chao Li wrote:
> > When gin_tuple.h was introduced by commit 8492feb[1], the file header
> > comment incorrectly referred to gin.h. Update the comment to mention
> > gin_tuple.h instead.
>
> Indeed. Will push
On Mon, 22 Sept 2025 at 12:49, David Rowley wrote:
>
> On Mon, 22 Sept 2025 at 11:56, Richard Guo wrote:
> > Nice catch. Will push the patch.
>
> I was just working on a script to find others and it highlighted a
> bunch more. Do you still want to do this one, or should I take them
> all in one
On Sun, Sep 21, 2025 at 6:35 AM Junwang Zhao wrote:
> After further study, this should not be a problem, since the address of
> &gplan->plan is the same as gplan, but the code is a little bit confusing
> at first glance, I think *return (Plan *) gplan* is easier to understand
> but I don't insist
On Mon, Sep 22, 2025 at 8:10 AM Chao Li wrote:
> When gin_tuple.h was introduced by commit 8492feb[1], the file header comment
> incorrectly referred to gin.h. Update the comment to mention gin_tuple.h
> instead.
Indeed. Will push the patch.
- Richard
On Sun, Sep 21, 2025 at 11:54 PM Steve Lau wrote:
> Found a tiny incorrect comment of RangeTblEntry, field "alias" is actually
> above "join_using_alias", so the code comment could be updated to reflect the
> current field order:
>
> > join_using_alias is an alias clause attached directly to JOI
Hi Hacker,
When gin_tuple.h was introduced by commit 8492feb[1], the file header
comment incorrectly referred to gin.h. Update the comment to mention
gin_tuple.h instead.
[1]
https://git.postgresql.org/cgit/postgresql.git/commit/?id=8492feb98f6df3f0f03e84ed56f0d1cbb2ac514c
Best regards,
Chao Li
Michael Paquier writes:
> On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote:
>> So it seems to me that Hurd is not mature enough yet to test Postgres.
> I'd say that it is likely not mature enough for production. In terms
> of testing, that seems kind of OK. However, failures lik
> On Sep 21, 2025, at 22:48, Steve Lau wrote:
>
> Hi hackers!
>
> Found a tiny incorrect comment of RangeTblEntry, field "alias" is actually
> above "join_using_alias", so the code comment could be updated to reflect the
> current field order:
>
> > join_using_alias is an alias clause atta
On Fri, Sep 19, 2025 at 01:23:48PM +0300, Nazir Bilal Yavuz wrote:
> Nice catch! I am able to reproduce the problem and I confirm that the
> patch fixes it.
Right, will fix and backpatch. Please note f039c2244110, that has
changed the minimum version to be 0.57.2 on HEAD, and we still allow
an ol
On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote:
> So it seems to me that Hurd is not mature enough yet to test Postgres.
I'd say that it is likely not mature enough for production. In terms
of testing, that seems kind of OK. However, failures like the one you
are reporting here
On 9/21/25 19:34, Tom Lane wrote:
> Jim Jones writes:
>> That's indeed a much larger problem. Calling it from a session silently
>> delivers a "wrong" result --- I was expecting an error.
>
> Yeah, me too. See
>
> https://www.postgresql.org/message-id/2736425.1758475979%40sss.pgh.pa.us
>
Th
On Sep 12, 2025, at 13:53, Tom Lane wrote:
> That seems substantially more complicated than just moving which
> commit is considered the baseline. It might be less reliable too:
> if the exclusions are written sloppily, they might hide problems
> we'd rather find out about. (I do not regard val
On Sun, Sep 21, 2025 at 12:19 PM Jelte Fennema-Nio
wrote:
> On Sun, 21 Sept 2025 at 19:44, Tom Lane wrote:
> > Yeah, if it were 18-only we'd need a powwow about whether to break
> > release freeze. But since it's been there since 17 and nobody
> > noticed, I'm content to wait till after 18.0 to
On Sun, 21 Sept 2025 at 19:44, Tom Lane wrote:
> Yeah, if it were 18-only we'd need a powwow about whether to break
> release freeze. But since it's been there since 17 and nobody
> noticed, I'm content to wait till after 18.0 to fix it.
People definitely noticed[1], but I agree that there's no
On Fri, 2025-09-19 at 17:21 -0700, Jeff Davis wrote:
> --
> Versioning
> --
>
> Unlike other built-in collations, the order does depend on the
> version
> of Unicode...
> That means that indexes, including primary keys, can become
> inconsistent after a major version upgrade...
T
On Sun, Sep 21, 2025 at 01:44:11PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Given that this problem exists in PG 17, I assume this will not affect
> > the PG 18 release this week.
>
> Yeah, if it were 18-only we'd need a powwow about whether to break
> release freeze. But since it's be
Bruce Momjian writes:
> Given that this problem exists in PG 17, I assume this will not affect
> the PG 18 release this week.
Yeah, if it were 18-only we'd need a powwow about whether to break
release freeze. But since it's been there since 17 and nobody
noticed, I'm content to wait till after 1
On Sun, Sep 21, 2025 at 01:32:59PM -0400, Tom Lane wrote:
> but that's gone missing :-(. Apparently, we refactored things enough
> that ReadBufferExtended is not used for a simple seqscan, and since
> that's where the check for an other-session temp table is, we get
> no error and instead bogus re
Jim Jones writes:
> That's indeed a much larger problem. Calling it from a session silently
> delivers a "wrong" result --- I was expecting an error.
Yeah, me too. See
https://www.postgresql.org/message-id/2736425.1758475979%40sss.pgh.pa.us
regards, tom lane
In session 1:
regression=# create temp table tt(f1 int);
CREATE TABLE
regression=# insert into tt values(44);
INSERT 0 1
regression=# \d tt
Table "pg_temp_77.tt"
Column | Type | Collation | Nullable | Default
+-+---+--+-
f1 | integer
ne 21. 9. 2025 v 18:42 odesílatel Jim Jones
napsal:
>
>
> On 9/21/25 17:37, Jim Jones wrote:
> >
> >
> > On 9/21/25 16:59, Tom Lane wrote:
> >> There's a larger issue here though: a function such as Jim shows
> >> is a normal function, probably stored in the public schema, and
> >> by default oth
On 9/21/25 17:37, Jim Jones wrote:
>
>
> On 9/21/25 16:59, Tom Lane wrote:
>> There's a larger issue here though: a function such as Jim shows
>> is a normal function, probably stored in the public schema, and
>> by default other sessions will be able to call it. But it will
>> certainly not
On Sun, Sep 21, 2025 at 5:52 PM Junwang Zhao wrote:
>
> Hi Robert,
>
> On Fri, Sep 19, 2025 at 1:23 AM Robert Haas wrote:
> >
> > On Tue, Sep 16, 2025 at 11:27 AM Robert Haas wrote:
> > > I'm inclined to change the code like this to fix it:
> > >
> > > char *replacement_type = "???";
>
Hi,
> From ad7c856e964b614507a06342c2acbf10bfa4855c Mon Sep 17 00:00:00 2001
> From: Jakub Wartak
> Date: Tue, 9 Sep 2025 14:30:48 +0200
> Subject: [PATCH v1] aio: warn user if combined io_uring memory mappings are
> unavailable
>
> In f54af9f2 we have added solution to avoid connection and di
On 9/21/25 16:59, Tom Lane wrote:
> There's a larger issue here though: a function such as Jim shows
> is a normal function, probably stored in the public schema, and
> by default other sessions will be able to call it. But it will
> certainly not work as desired for them, since they can't acce
Hi Pavel
On 9/21/25 14:33, Pavel Stehule wrote:
> i understand your motivation, but with this warning temp tables cannot
> be used in SQL function due log overhead.
My intention was not to warn on every function call. The WARNING is only
emitted once at CREATE FUNCTION time, similar to how CREATE
On Tue, Aug 26, 2025 at 1:53 PM Amul Sul wrote:
>
[..patch]
Hi Amul!
0001: LGTM, maybe I would just slightly enhance the commit message
("This is in preparation for adding a second source file to this
directory.") -- maye bit a bit more verbose or use a message from
0002?
0002: LGTM
0003: LGTM
On Wed, Sep 3, 2025 at 5:10 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, September 2, 2025 11:03 PM Robert Haas
> wrote:
> >
> > On Wed, Jul 23, 2025 at 11:44 PM Amit Kapila
> > wrote:
> >
> > If it is in fact important to acquire the commit timestamp after setting
> > delayChkptFlags, you'd
ne 21. 9. 2025 v 16:59 odesílatel Tom Lane napsal:
> "David G. Johnston" writes:
> > I’m surprised that this is how the system works and I agree that either
> we
> > should add this notice or remove the one for create view. Even more
> > because there is no syntax for directly creating a tempor
Hi hackers!
Found a tiny incorrect comment of RangeTblEntry, field "alias" is actually
above "join_using_alias", so the code comment could be updated to reflect the
current field order:
> join_using_alias is an alias clause attached directly to JOIN/USING. It is
> different from the alias fiel
"David G. Johnston" writes:
> I’m surprised that this is how the system works and I agree that either we
> should add this notice or remove the one for create view. Even more
> because there is no syntax for directly creating a temporary function -
It is possible to do
CREATE FUNCTION pg_temp.f
On 21/09/2025 13:49, Jim Jones wrote:
WARNING: function defined with BEGIN ATOMIC depends on temporary
relation "tmp"
DETAIL: the function will be dropped automatically at session end.
CREATE FUNCTION
In addition to what others have said, this DETAIL line needs to be
contextual. The temp
On Sunday, September 21, 2025, Jim Jones wrote:
> Hi Pavel
>
> On 9/21/25 14:33, Pavel Stehule wrote:
> > i understand your motivation, but with this warning temp tables cannot
> > be used in SQL function due log overhead.
>
> My intention was not to warn on every function call. The WARNING is on
Hi
ne 21. 9. 2025 v 13:49 odesílatel Jim Jones
napsal:
> Hi,
>
> While reviewing a patch I noticed that SQL functions defined with BEGIN
> ATOMIC can reference temporary relations, and such functions are
> (rightfully) dropped at session end --- but without any notification to
> the user:
>
> $
Hi,
While reviewing a patch I noticed that SQL functions defined with BEGIN
ATOMIC can reference temporary relations, and such functions are
(rightfully) dropped at session end --- but without any notification to
the user:
$ /usr/local/postgres-dev/bin/psql postgres
psql (19devel)
Type "help" for
Hi,
On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote:
> 02.07.2025 02:53, Michael Paquier wrote:
> > Catching up on this thread after-the-fact, specifically looking at
> > 29213636e6cd as I did the original check tweaked here for O_RDONLY.
> > Agreed that a backpatch should be OK a
Hi Robert,
On Fri, Sep 19, 2025 at 1:23 AM Robert Haas wrote:
>
> On Tue, Sep 16, 2025 at 11:27 AM Robert Haas wrote:
> > I'm inclined to change the code like this to fix it:
> >
> > char *replacement_type = "???";
> >
> > ...in the hopes of still producing a warning here if somebody a
54 matches
Mail list logo
