Thank you everyone for the reviews, feedback and the test.
Please find attached a new version of the patch.
On Tue, Sep 23, 2025 at 7:11 AM Chao Li wrote:
>
>
> On Sep 23, 2025, at 07:35, David Rowley wrote:
>
> On Tue, 23 Sept 2025 at 11:21, Chao Li wrote:
>
> I guess that because earlier in
On Tue, Sep 23, 2025 at 01:43:47AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> The result I had was good enough, so applied. The CI was OK, the
>> buildfarm may have a different opinion.
>
> This patch seems to be rather full of arbitrary casts to or
> from Datum, which is no longer okay
Hi
po 22. 9. 2025 v 23:31 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Monday, September 22, 2025, Tom Lane wrote:
>
>> =?utf-8?q?=D0=A7=D1=83=D0=BC=D0=B0=D0=BA_=D0=90=D0=BD=D1=82=D0=BE=D0=BD?=
>> writes:
>> > This patch adds a unified mechanism for declaring and usin
Hi Hackers,
While reviewing Json Simplified Accessor Support [1], I noticed that with
the new accessor, it will show the actual json field name, for example:
```
evantest=# select (j).b.c from ttt;
c
20
(2 rows)
```
"c" is the last segment of the accessor, so the column name shows as "c".
Hi,
Again, found an incorrect function comment of stringToNodeInternal(). Wrong
function name is put to the comment, I guess it was from a copy/paste error.
Best regards,
Chao Li (Evan)
-
HighGo Software Co., Ltd.
https://www.highgo.com/
v1-0001-Fix-incorrect-function-commen
> 3)
> + ereport(LOG,
> + (errmsg("reset synced flag for replication slot \"%s\"",
> + NameStr(s->data.name;
>
> a) Shall we change it to DEBUG1?
> b) Shall the msg be:
> synced flag reset for replication slot \"%s\" during promotion
>
I think this can stay as a LOG message, it only runs once
Attached is the updated v19 patches. Mostly applied changes suggested
by Chao.
>> Overall LGTM. Just a few small comments:
>
>> 1 - 0001
>> ```
>> --- a/src/backend/parser/parse_func.c
>> +++ b/src/backend/parser/parse_func.c
>> @@ -98,6 +98,7 @@ ParseFuncOrColumn(ParseState *pstate, List *funcna
On Wed, Sep 24, 2025 at 9:42 AM shveta malik wrote:
>
> On Tue, Sep 23, 2025 at 6:41 PM Ashutosh Sharma wrote:
> >
> > > 3)
> > > + ereport(LOG,
> > > + (errmsg("reset synced flag for replication slot \"%s\"",
> > > + NameStr(s->data.name;
> > >
> > > a) Shall we change it to DEBUG1?
> > > b)
Hi,
On Mon, Sep 22, 2025 at 8:56 PM Jeff Davis wrote:
> On Sat, 2025-09-13 at 22:04 -0700, Bharath Rupireddy wrote:
> > Thanks for looking at this. Yes, the WAL writers can zero out flushed
> > buffers before WALReadFromBuffers gets to them. However,
> > WALReadFromBuffers was intentionally desi
hi.
please check the attached latest version.
I did some minor cosmetic changes.
similar to commit 16a0039, we can just use ShareUpdateExclusiveLock to validate
existing not-valid not null constraints
for the below issue (should the last UPDATE fail or not),
I have already created a thread at [1
On Wed, Sep 24, 2025 at 2:02 AM Nathan Bossart wrote:
>
> On Mon, Sep 22, 2025 at 03:05:44PM -0500, Nathan Bossart wrote:
> > I was able to improve the hex_decode() implementation a bit.
>
> I took a closer look at how hex_decode() performs with smaller inputs.
> There are some small regressions,
On Sat, Sep 20, 2025 at 12:13 AM Timur Magomedov
wrote:
>
> Hi Peter!
>
> > What exactly did Valgrind report? For example, you said the
> > VciScanState points beyond allocated memory. Do you have any more
> > clues, like where that happened? Did you discover where that (smaller
> > than it should
Testing via the Injection Point has been successfully completed.
> The option is named track_counts.
Regarding the option name track_counts in PgStat_KindInfo.
In my personal opinion, I was just wondering that it shares
the same name as the GUC track_counts(pgstat_track_counts in the source code).
On Mon, Sep 22, 2025 at 11:30:00PM +0300, Alexander Lakhin wrote:
> I reproduced the issue locally and found that
> /* total elapsed time in this function call */
> INSTR_TIME_SET_CURRENT(total);
> INSTR_TIME_SUBTRACT(total, fcu->start);
> sometimes gives total.ticks = 0.
>
On Wed, Sep 24, 2025 at 10:23 AM Tom Lane wrote:
> Yeah, I don't think the havingClause being constant-false is the
> key point here. I've not looked closely at 67a54b9e, but I suspect
> that anything Var-free is potentially an issue. Or it might even
> fail for something that has Vars but is no
On Tue, Sep 23, 2025 at 11:34:56AM -0400, Tom Lane wrote:
> 18.0 is what it is. If this is the most serious bug in it, I'll be
> a bit surprised. Take your time, fix it properly.
+1
--
nathan
[ getting back to this... ]
"Joel Jacobson" writes:
> I'm withdrawing the latest patches, since they won't fix the scalability
> problems, but only provide some performance improvements by eliminating
> redundant IPC signalling. This could also be improved outside of
> async.c, by optimizing Proc
"David G. Johnston" writes:
> As you note - moving runtime checks to "SET" time has value and this patch
> brings that value. But it is not evident there is enough value to take on
> the added complexity. There are few to no requests asking for this ability.
If anything, I'd say we have decades
On Mon, Sep 22, 2025 at 05:21:35PM +0530, shveta malik wrote:
> On Mon, Sep 22, 2025 at 4:35 PM Amit Kapila wrote:
> >
> > On Mon, Sep 22, 2025 at 1:41 PM Bertrand Drouvot
> > wrote:
> > >
> > > >
> > > > Since other statistics counter names are camel cases I think it's
> > > > better to follow t
Michael Paquier writes:
> On Tue, Sep 23, 2025 at 01:43:47AM -0400, Tom Lane wrote:
>> This patch seems to be rather full of arbitrary casts to or
>> from Datum, which is no longer okay. You need to be using
>> the appropriate conversion macros, such as PointerGetDatum.
> Right, this can ve repr
On Tue, 23 Sept 2025 at 15:49, 邱宇航 wrote:
> I've noticed that two GROUP BY ROLLUP queries behave differently in v17
> compared to master and REL_18_STABLE. The issue can be reproduced by
> following SQL:
>
> After some git bisect work, I traced the root cause:
> - The first issue was introduced by
On Mon, Sep 15, 2025 at 8:11 PM suyu.cmj wrote:
>
>
> Additionally, while studying the InvalidatePossiblyObsoleteSlot(), I noticed
> a behavioral difference between PG15 (and earlier) and PG16 (and later). In
> PG15 and earlier, while attempting to acquire a slot, if the slot's
> restart_lsn ad
On Tue, Sep 23, 2025 at 11:30 AM Masahiko Sawada wrote:
>
> On Wed, Aug 27, 2025 at 9:36 PM Ashutosh Bapat
> wrote:
> >
> > Ok. I am interested in knowing how you think we should keep track of
> > the high watermark.
> >
> > Do we keep it updated as new maxima are found? And keep reporting the
>
On Tue, Sep 23, 2025 at 1:11 PM Ajin Cherian wrote:
>
> Attaching v3 with the above code changes.
>
Thanks for the patch. Please find a few comments:
1)
+ if (!StandbyMode && slot->data.synced)
+ {
+ ReplicationSlotAcquire(NameStr(slot->data.name), false, true);
+ slot->data.synced = false;
+ Re
On 9/23/25 03:20, David Rowley wrote:
> On Tue, 23 Sept 2025 at 13:01, Tomas Vondra wrote:
>>
>> On 9/23/25 02:02, David Rowley wrote:
>>> Ok cool. We're just in the freeze for 18.0 at the moment. Once that's
>>> over, should I take care of this, or do you want to?
>>>
>>
>> Feel free to fix, b
Hi,
On 2025-09-23 17:45:19 +0530, Ashutosh Bapat wrote:
> On Tue, Sep 23, 2025 at 11:30 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Aug 27, 2025 at 9:36 PM Ashutosh Bapat
> > wrote:
> > >
> > > Ok. I am interested in knowing how you think we should keep track of
> > > the high watermark.
> > >
On Tue, Sep 23, 2025 at 12:14 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Fri, Sep 19, 2025 at 08:11:23PM +0530, Ashutosh Bapat wrote:
> > On Fri, Sep 19, 2025 at 11:48 AM shveta malik
> > wrote:
> > >
> > 0001 is the previous patch
> > 0002 changes addressing your and Bertrand's comments.
>
> Tha
On Mon, Sep 22, 2025 at 4:21 PM Ajin Cherian wrote:
>
>
> Created a patch v13 with these changes.
>
Please find a few comments:
1)
+ /* update the failure structure so that it can be freed on error */
+ fparams.slot_names = slot_names;
+
Since slot_names is assigned only once, we can make the a
Re: Jacob Champion
> > > Since nothing in libpq should need curl for compiling, should we drop
> > > it there instead?
> >
> > The static build (libpq.a) still needs libcurl. The module is only
> > compiled for use by the shared library.
>
> Sorry, typing too fast in the airport. The _clients_ of
Re: To Jacob Champion
> It turns out that pkg-config is picky when it doesn't find the .pc
> files listed in Requires.private. So, without libcurl4-openssl-dev
> installed:
What I didn't say explicitly in the last message is that I want to
avoid that all programs now build-depending on libpq-dev w
On Tue, Sep 23, 2025 at 11:38:22AM +0200, Peter Eisentraut wrote:
> That said, I did go overboard here and converted all the struct/union
> combinations I could find, but I'm not necessarily proposing to apply
> all of them. I'm proposing patches 0001 through 0004, which are
> relatively simple or
Hi,
On 2025-09-23 14:26:08 +, AIX PG user wrote:
> Thank you for your feedback and for highlighting the importance of
> Meson-based builds.
>
> We fully recognize the long-term objective of transitioning away from
> make-based builds, and we are actively working on reviving Meson support for
> 2025年9月23日 15:38，David Rowley 写道：
>
> If you check the release notes and the commit message for f5050f795
> you'll see that it does mention that wrong results could be returned.
>
> What wasn't mentioned was that this wasn't fixed in prior versions.
> The reason being is that the fix required
On Thu, Sep 11, 2025 at 1:55 PM root wrote:
> Thanks for the feedback. This is v5 of the patchset, updated following your
> comments:
>
> - Moved the function pointer definitions out of common headers and
> into src/port, consistent with existing practice.
There is no attachment in this thread
On Tue, Sep 23, 2025 at 1:22 PM Peter Smith wrote:
>
> Hi Shubham,
>
> Here are some v10 review comments.
>
> ==
> 1. GENERAL
>
> A couple of my review comments below (#4, #7) are about the tense of
> the info messages; My comments are trying to introduce some
> consistency in the patch but un
On Thu, Sep 18, 2025 at 2:59 PM John Naylor wrote:
> The only change I made for v9 is to reword the regression test
> addition from "upgrades" to "change". I'm planning to commit next week
> unless there are objections. (If anyone otherwise busy with the PG18
> release wants a chance to weigh in,
Hi Amit,
On Tue, Sep 23, 2025 at 1:00 PM Shlok Kyal wrote:
>
> On Tue, 23 Sept 2025 at 09:55, Amit Kapila wrote:
> >
> > On Fri, Sep 12, 2025 at 2:34 PM Shlok Kyal wrote:
> > >
> > > I have attached the updated v4 patch
> > >
> >
> > +# Cannot be set synchronized_standby_slots to a reserved slo
On Tue, Sep 23, 2025 at 2:15 PM Jacob Champion
wrote:
> > That would be in Cflags.private.
>
> Yes.
The FAQ you cite says
> In either case, pkg-config will output the [private dependency's] compiler
> flags when --static is used or not.
which seems awfully counterproductive, and was apparently
On Tue, Sep 23, 2025 at 11:11 PM Ashutosh Sharma wrote:
>
> > 3)
> > + ereport(LOG,
> > + (errmsg("reset synced flag for replication slot \"%s\"",
> > + NameStr(s->data.name;
> >
> > a) Shall we change it to DEBUG1?
> > b) Shall the msg be:
> > synced flag reset for replication slot \"%s\" dur
On Tue, Sep 23, 2025 at 4:44 AM Nathan Bossart wrote:
>
> 0001 essentially reverts commit c6a43c2, and instead fixes the problem
> (MSVC dislikes casts to the same type) by omitting the cast in the
> problematic line in pg_lfind32(). While working on optimizing hex_encode()
> and hex_decode() [0]
Hi Andres,
> It worked without meson changes just before the AIX support was dropped. I do
> not see why you *need* that meson patch, rather it just being convenient -
> after all I had made it work before, without that.
I was able to build successfully using Meson on PostgreSQL 16. However, when
On Sep 23 2025, at 12:46 pm, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Sep 23, 2025 at 01:43:47AM -0400, Tom Lane wrote:
>>> This patch seems to be rather full of arbitrary casts to or
>>> from Datum, which is no longer okay. You need to be using
>>> the appropriate conversion macro
On Tue, Sep 23, 2025 at 12:42 PM Christoph Berg wrote:
> Maybe by the letter, but I think we have a real problem and need to do
> something.
If I break Wolfgang's use case again, we will still have a real problem.
> > I think we can't avoid it; if anyone wants to get Windows support
> > working
While experimenting with a patch that adds a GUC, I was befuddled by
the new GUC's failure to be available after I rebuilt and reinstalled.
I eventually realized that the problem is that utils/misc/Makefile
has no idea that guc_tables.o needs to be rebuilt after changing
guc_tables.inc.c. Of cours
On Tue, Sep 23, 2025 at 01:39:00PM -0500, Sami Imseih wrote:
> The refcount reaches 0 when all backends release their references to the
> stat, so if something like pg_stat_statements relies on a count for
> deallocation purposes (to stay within the max), and that value only
> decrements when all r
On 9/23/25 21:13, Konstantin Knizhnik wrote:
> On 23/09/2025 6:11 PM, Tomas Vondra wrote:
>
>> Hi,
>>
>> I kept looking at this, and unfortunately the it seems a bit worse :-(
>>
>> Fixing the overflow is easy enough - adding the cast does the trick.
>>
>> But then there's the second issue I me
On Tue Sep 23, 2025 at 1:11 PM -03, Arseniy Mukhin wrote:
>> Thanks for the explanation! I'm just not sure if I understand why do we
>> need the LWLockAcquire(NotifyQueueLock, LW_EXCLUSIVE) on
>> PreCommit_Notify() if we already have the
>> LockSharedObject(DatabaseRelationId, InvalidOid, 0, Access
Hi,
On Wed, Sep 24, 2025 at 11:38:30AM +0530, shveta malik wrote:
> On Wed, Sep 24, 2025 at 11:08 AM Ashutosh Bapat
> wrote:
> >
> > In WalSndWriteData() we can't rely on what happens in a low level API
> > like socket_putmessage(). And we are counting the number of bytes in
> > the logically dec
48 matches
Mail list logo
