On Thu, May 8, 2025 at 5:50 PM Etsuro Fujita wrote:
> Attached is an updated version of the patch.
Here is a new version of the patch where I added a comment for a new
function, fixed indentation, and added the commit message. If there
are no objections, I will push this as a master-only fix, as
> On 25 May 2025, at 1:01 AM, David E. Wheeler wrote:
>
> On May 24, 2025, at 17:55, David E. Wheeler wrote:
>
>> And now I see my patch broke the grammar because I left some of my fiddling
>> in there. Apologies. Here’s an updated patch with the updated keyword map,
>> too.
>
> No, reall
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, failed
Hi Michael,
Thank you for the patch.
I suggest to add into documentation
Thomas Munro writes:
> Can you get a core and print *ioh in the debugger?
So far, I've failed to get anything useful out of core files
from this failure. The trace goes back no further than
(lldb) bt
* thread #1
* frame #0: 0x00018de39388 libsystem_kernel.dylib`__pthread_kill + 8
That's
> If you subtract recently dead from that number within the heap
> implementation, then it will no longer
> reflect non-removable tuples and the log message in the cluster
> function "found %.0f removable, %.0f nonremovable row versions" will no
> longer be correct.
Yes, that's correct. I did no
On Sun, May 25, 2025 at 9:00 AM Alexander Lakhin wrote:
> Hello Thomas,
> 24.05.2025 14:42, Thomas Munro wrote:
> > On Sat, May 24, 2025 at 3:17 PM Tom Lane wrote:
> >> So it seems that "very low-probability issue in our Mac AIO code" is
> >> the most probable description.
> > There isn't any mac
Hi Michael
Yeah, that's a good point. I would also question what's the benefit
in using GB18030 over UTF-8, though. An obvious one I can see is
because legacy applications never get updated.
The GB18030 encoding standard is a mandatory Chinese character encoding
standard required by regulati
On May 24, 2025, at 17:55, David E. Wheeler wrote:
> And now I see my patch broke the grammar because I left some of my fiddling
> in there. Apologies. Here’s an updated patch with the updated keyword map,
> too.
No, really :sigh:
D
v5-0001-Add-additional-jsonpath-string-methods.patch
Desc
On May 24, 2025, at 17:46, David E. Wheeler wrote:
> Oh, and I forgot to mention, src/backend/utils/adt/jsonpath_scan.l looks like
> it has a ton of duplication in it. Shouldn’t it just add the new keywords,
> something like:
And now I see my patch broke the grammar because I left some of my f
On May 24, 2025, at 17:39, David E. Wheeler wrote:
> I’ve attached a new patch with docs.
Oh, and I forgot to mention, src/backend/utils/adt/jsonpath_scan.l looks like
it has a ton of duplication in it. Shouldn’t it just add the new keywords,
something like:
```
@@ -415,6 +415,11 @@ static co
On May 24, 2025, at 12:51, Florents Tselai wrote:
> I think the patch is still in reasonably good shape and hasn’t changed much
> since September 24.So yes, I’d hope there are still some valid points to
> consider or improve.
Okay, here’s a review.
Patch applies cleanly.
All tests pass.
I'm
Hello Thomas,
24.05.2025 14:42, Thomas Munro wrote:
On Sat, May 24, 2025 at 3:17 PM Tom Lane wrote:
So it seems that "very low-probability issue in our Mac AIO code" is
the most probable description.
There isn't any macOS-specific AIO code so my first guess would be
that it might be due to aa
> On Sun, Apr 13, 2025 at 04:59:54AM GMT, Thomas Munro wrote:
> It's hard to know how to set io_workers=3. If it's too small,
> io_method=worker's small submission queue overflows and it silently
> falls back to synchronous IO. If it's too high, it generates a lot of
> pointless wakeups and sched
> On 24 May 2025, at 7:08 PM, David E. Wheeler wrote:
>
> On May 23, 2025, at 13:52, Tom Lane wrote:
>
>>> I assume you mean that they’re set at initdb time, so there’s no mutability
>>> concern?
>>
>> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
>> our philosophical
On May 23, 2025, at 13:52, Tom Lane wrote:
>> I assume you mean that they’re set at initdb time, so there’s no mutability
>> concern?
>
> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
> our philosophical debate about how immutable is immutable. But as
> long as the func
> In v17, we are a bit smarter with the numbering, with a normalization
> giving the following, starting at $1:
> select where $5 in ($1, $2, $3) and $6 = $4
>
> So your argument about the $n parameters is kind of true, but I think
> the numbering logic in v17 to start at $1 is a less-confusing res
> On Sun, May 25, 2025 at 02:15:12AM GMT, Thomas Munro wrote:
> On Sun, May 25, 2025 at 1:56 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I've been rebasing the patch for online resizing of shared memory, and
> > noticed something strange about IoWorkerMain: although it sets the
> > handler
On Sun, May 25, 2025 at 1:56 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I've been rebasing the patch for online resizing of shared memory, and
> noticed something strange about IoWorkerMain: although it sets the
> handler SignalHandlerForConfigReload, it doesn't look like it acts upon
> Conf
On Saturday, May 24, 2025, jian he wrote:
> On Sat, May 24, 2025 at 2:39 PM Feike Steenbergen
> wrote:
> >
> > The loophole is this:
> >
> > - the generated virtual column can use a user-defined function
> > - when running SELECT against that column by a superuser
> > the function is called wi
I would also argue for treating this as a bug and back-porting to all
supported versions - a quick look at v13 seems to confirm that the
wrapped code has not changed at least since then.
I don't think we can claim the current state is Working As Intended
unless someone stands up and says they real
Hi,
I've been rebasing the patch for online resizing of shared memory, and
noticed something strange about IoWorkerMain: although it sets the
handler SignalHandlerForConfigReload, it doesn't look like it acts upon
ConfigReloadPending. From what I see it happens because it only does
CHECK_FOR_INTER
Hello Everybody,
Currently setting `session_replication_role` to `replica` disables
foreign key checks allowing, among other things, free table copy order
and faster CDC apply in logical replication.
But two other cases of foreign keys are still restricted or blocked
even with this setting
1. F
On Sat, May 24, 2025 at 2:39 PM Feike Steenbergen
wrote:
>
> The loophole is this:
>
> - the generated virtual column can use a user-defined function
> - when running SELECT against that column by a superuser
> the function is called within the context of a superuser
> - this in turn allows the
Hi, Amit!
Thank you for your attention to this patchset!
On Sat, May 24, 2025 at 2:15 PM Amit Kapila wrote:
> On Sat, May 24, 2025 at 4:08 PM Alexander Korotkov
> wrote:
> >
> > I spend more time on this. The next revision is attached. It
> > contains revised comments and other cosmetic chan
Hi,
On Sat, May 24, 2025 at 10:10 AM Tom Lane wrote:
> The DirectModify code path relies on PG_TRY blocks to ensure that it
> releases the PGresult for the foreign modify command, but that can't
> work because (at least in cases with RETURNING data) the PGresult has
> to survive across successive
Dear all users of the pgsql-hackers @ lists.postgresql.org mailing list,
A lot of people always send e-mails to the bad mailing list address.
Can you ONLY send to pgsql-hackers @ lists.postgresql.org?
It is same for other lists from lists.postgresql.org.
It must not be used: pgsql-hackers @ post
On Sat, May 24, 2025 at 3:17 PM Tom Lane wrote:
> So it seems that "very low-probability issue in our Mac AIO code" is
> the most probable description.
There isn't any macOS-specific AIO code so my first guess would be
that it might be due to aarch64 weak memory reordering (though Andres
speculat
On Sat, May 24, 2025 at 3:58 PM Dilip Kumar wrote:
>
> On Sat, May 24, 2025 at 11:00 AM Amit Kapila wrote:
> >
> > On Sat, May 24, 2025 at 10:29 AM Dilip Kumar wrote:
> > >
> > > On Sat, May 24, 2025 at 10:04 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zh
On Sat, May 24, 2025 at 4:08 PM Alexander Korotkov wrote:
>
> I spend more time on this. The next revision is attached. It
> contains revised comments and other cosmetic changes. I'm going to
> backpatch 0001 to all supported branches,
>
Is my understanding correct that we need 0001 because
Ph
On Sat, May 24, 2025 at 11:00 AM Amit Kapila wrote:
>
> On Sat, May 24, 2025 at 10:29 AM Dilip Kumar wrote:
> >
> > On Sat, May 24, 2025 at 10:04 AM Dilip Kumar wrote:
> > >
> > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote:
> > > >
> > > Looking at v31-0001 again, most of it looks fine e
On Fri, May 23, 2025 at 12:10 AM Alexander Korotkov
wrote:
>
> Hi, Vitaly!
>
> On Tue, May 20, 2025 at 6:44 PM Vitaly Davydov
> wrote:
> >
> > Thank you very much for the review!
> >
> > > The patchset doesn't seem to build after 371f2db8b0, which adjusted
> > > the signature of the INJECTION_PO
> On 24 May 2025, at 12:24 PM, Álvaro Herrera wrote:
>
> On 2025-May-24, Florents Tselai wrote:
>
>> I aggree with having more READMEs around the src tree.
>> It’s true that a lot of doc content found in VII. Internals is dev-oriented,
>> but imho it should be closer to the src (and more succi
On 2025-May-24, Florents Tselai wrote:
> I aggree with having more READMEs around the src tree.
> It’s true that a lot of doc content found in VII. Internals is dev-oriented,
> but imho it should be closer to the src (and more succinct/less verbose too).
Maybe these READMEs can simply contain lit
On 2025-May-21, Andres Freund wrote:
> Hi,
>
> In [1] I added some verification to projection building, to check if the
> tupleslot passed to ExecBuildProjectionInfo() is compatible with the target
> list. One query in merge.sql [2] got flagged.
>
> Trying to debug that issue, I found another p
I want to test PostgreSQL 18 beta on Debian 13 (trixie),
but "libpq5" (18-beta) is missing
My sources configuration:
~
Types: deb
URIs: https://apt.postgresql.org/pub/repos/apt/
Suites: trixie-pgdg
Components: main 17 18
Enabled: yes
Architectures: amd64
Sign
Hello,
I would like to propose a modification to the internal_get_result_type
function, which is called from *get_call_result_type*. Specifically, I
recommend altering it to return a copy of *rsinfo->expectedDesc*.
Currently, callers are responsible for copying the tuple descriptor
returned from *
36 matches
Mail list logo
