On Tue, Apr 22, 2025 at 11:19 AM jian he
wrote:
> On Tue, Apr 22, 2025 at 11:45 AM Ashutosh Bapat
> wrote:
> >
> >
> > While looking at this I realised that a generated column may end up
> being part of the partition key if the partition key expression contains a
> whole row reference. Attached
Hi,
On Mon, Apr 21, 2025 at 10:17:40AM +0900, Michael Paquier wrote:
> On Tue, Apr 15, 2025 at 05:50:32AM +, Bertrand Drouvot wrote:
> > Sorry, can't look at the details right now but it might be linked to
> > 039549d70f6 which is recent enough and in this area. Will give it a look
> > once
On Tue, Apr 22, 2025 at 11:45 AM Ashutosh Bapat
wrote:
>
>
> While looking at this I realised that a generated column may end up being
> part of the partition key if the partition key expression contains a whole
> row reference. Attached patch also has a fix and a testcase for the same.
> PARTI
On Tue, Apr 15, 2025 at 04:37:51PM +0530, Rahila Syed wrote:
> The function actually retrieves an array not a list, so the comment and
> the function name may be misleading.
> This function not only retrieves an array of injection points but also
> the number of injection points. Would it be more e
Dear Michael,
> Thanks, I've applied some slight tweaks, and applied the result down
> to v17, leaving the heap_update point alone.
Thanks, I confirmed your commit on HEAD and LGTM.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On Tue, Apr 22, 2025 at 11:23 AM Amit Kapila wrote:
>
> On Fri, Apr 18, 2025 at 9:58 AM Amit Kapila wrote:
> >
> > On Thu, Apr 17, 2025 at 6:14 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > -
> > > Fix
> > > -
> > >
> > > I think we should keep the confirmed_flush even if the previous
My previous v2 patch needed a rebase anyway, so I've taken this
opportunity also to restructure everything. Although it would be
easier to post a single patch, some of the changes are still
debatable. For this reason, now I've split the previous v2 patch into
multiple parts, hoping that it will hel
On Mon, Apr 21, 2025 at 2:42 PM jian he wrote:
> On Mon, Apr 21, 2025 at 4:02 PM Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/04/21 11:30, jian he wrote:
> > > hi.
> > > While trying to make the virtual generated column be part of the
> partition key,
> > > I found this bug.
>
>
I noticed that t
On Mon, Apr 21, 2025 at 12:10:51PM +, Hayato Kuroda (Fujitsu) wrote:
> Thanks for suggesting them. ISTM, you are correct. PSA updated version.
Thanks, I've applied some slight tweaks, and applied the result down
to v17, leaving the heap_update point alone.
--
Michael
signature.asc
Descriptio
On Fri, Apr 18, 2025 at 9:58 AM Amit Kapila wrote:
>
> On Thu, Apr 17, 2025 at 6:14 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > -
> > Fix
> > -
> >
> > I think we should keep the confirmed_flush even if the previous synced
> > restart_lsn/catalog_xmin is newer. Attachments include a patch fo
On Tue, 22 Apr 2025 at 12:27, David G. Johnston
wrote:
> On Monday, April 21, 2025, David Rowley wrote:
>> Does anyone have any opinion on the wording I'm proposing in the attached?
>
> I like it. It removes the problematic wording and moves the reference to
> —all closer to the front to aid in
I noticed that following CF entry only modifies code comments but
CFbot complains it fails on Windows - Server 2019, VS 2019 - Meson &
ninja.
https://commitfest.postgresql.org/patch/5679/
https://cirrus-ci.com/task/6243124407697408
I guess this means that either:
1) master branch has some issues
Hi Michael,
Thanks for the feedback and the suggested patch sequence. I completely
agree—we must minimize storage overhead when dictionaries aren’t used,
while ensuring varattrib_4b remains extensible enough to handle future
compression metadata beyond dictionary ID (for other algorithms). I’ll
ex
Dear Andrew,
> What is that extra stuff doing on the end of your LD_LIBRARY_PATH?
> That looks wrong. Do you have LD_LIBRARY_PATH set in your calling environment?
To confirm, did you ask the LD_LIBRARY_PATH on my bash? Here it is:
```bash
$ echo $LD_LIBRARY_PATH
/usr/local/pgsql/lib:/usr/local/
Hi Robert,
Thank you for your feedback on the patch. You’re right that my
proposed design will introduce more dictionary dependencies as
dictionaries grow, I chose this path specifically to avoid changing
existing system behavior and prevent perf regressions in CTAS and
related commands.
After re
On Monday, April 21, 2025, David Rowley wrote:
>
> Does anyone have any opinion on the wording I'm proposing in the attached?
>
I like it. It removes the problematic wording and moves the reference to
—all closer to the front to aid in skimming.
David J.
On Tue, 22 Apr 2025 at 08:53, Noboru Saito wrote:
> Regarding "to to" and "that that", I agree that they might be
> technically acceptable.
> However, I personally find them a bit harder to parse and they
> increase the chance of misreading for me.
> Your suggested alternative for "to to" is much
On Mon, Apr 21, 2025 at 03:22:28PM +0900, Michael Paquier wrote:
> Anyway, I don't think that there is much we can do under a
> PGRES_FATAL_ERROR in this code path when discarding the pipe results.
> As far as I can tell, the server has failed the query suddenly and the
> whole pipeline flow is bor
On Sat, Apr 19, 2025 at 5:04 AM Christoph Berg wrote:
> How about this:
>
> No libpq OAuth flows are available. (Try installing the libpq-oauth
> package.)
Tweaked for capitalization/punctuation rules, and removing the first
"libpq" mention (which I don't think helps a user of, say, psql):
Thank you for the review! I appreciate your detailed feedback.
Regarding "to to" and "that that", I agree that they might be
technically acceptable.
However, I personally find them a bit harder to parse and they
increase the chance of misreading for me.
Your suggested alternative for "to to" is mu
On Mon, Apr 21, 2025 at 11:46 AM Daniel Gustafsson wrote:
> We do, but with the current coding we call setJsonLexContextOwnsTokens
> immediately after creation which derefences the pointer without checkinf for
> allocation failure.
Right. (The flag does nothing on the OOM sentinel.)
> This means
Hi,
On Sat, 2025-04-19 at 14:03 +0200, Christoph Berg wrote:
> No libpq OAuth flows are available. (Try installing the libpq-oauth
> package.)
>
> People who have custom flows will likely know that they have to do
> anyway.
>
> Devrim: Does that match the package name you'd use?
On PGDG RPM w
> On 21 Apr 2025, at 20:28, Jacob Champion
> wrote:
>
> On Mon, Apr 21, 2025 at 11:20 AM Daniel Gustafsson wrote:
>> Sure, but I fear we'll get an endless stream of static analysis reports for
>> the
>> allocation leaking if we don't free it.
>
> But we do free it, in freeJsonLexContext(). Th
On Mon, Apr 21, 2025 at 11:20 AM Daniel Gustafsson wrote:
> Sure, but I fear we'll get an endless stream of static analysis reports for
> the
> allocation leaking if we don't free it.
But we do free it, in freeJsonLexContext(). That usage of the API goes
back to 2023, with 1c99cde2f344. Or am I
> On 21 Apr 2025, at 17:33, Jacob Champion
> wrote:
>
> On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson wrote:
>> Since there is no way to determine if the allocation succeeded from outside
>> of
>> the JSON api it might be better to keep the calloc and explicitly free it?
>
> I don't think
On Thu, Feb 20, 2025 at 10:05 AM Masahiko Sawada wrote:
>
> On Wed, Feb 19, 2025 at 1:56 AM Bertrand Drouvot
> wrote:
> >
> > Hi,
>
> Thank you for looking at the patches.
>
> >
> > On Mon, Feb 17, 2025 at 12:07:56PM -0800, Masahiko Sawada wrote:
> > > On Fri, Feb 14, 2025 at 2:35 AM Bertrand Dro
On Sun, Apr 20, 2025 at 10:12 AM Ivan Kush wrote:
> I'm testing OAuth Device Flow implementation on Google. Met several
> problems.
Hi Ivan, thank you for testing and reporting! Unfortunately, yeah,
Google is a known problem [1]. They've taken several liberties with
the spec, as you point out.
W
Last year the old Windows machine where I was running the buildfarm
member lorikeet died, and since then we've had no buildfarm coverage for
Cygwin. I now have a new (but slow) W11pro machine and I have been
testing out Cygwin builds on it. I wanted to have it running the TAP
tests, unlike lo
Rahila Syed writes:
> +1 for adding the assertion to increase the chances of this bug being
> caught by memory context infrastructure.
I verified that an assertion inside MemoryContextCreate would catch
this bug, so I added one (in 5ec8b01c3), and then pushed the main
fix at 80b727eb9.
> I had t
Apparently replication origins in tests are supposed to be prefixed with
"regress_". Here is a new patch with that fixed.
--
nathan
>From fa6a8a5a155a7beb50e54bfe42c81be26ffd428a Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 21 Apr 2025 10:53:15 -0500
Subject: [PATCH v3 1/1] Remove p
On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson wrote:
> Since there is no way to determine if the allocation succeeded from outside of
> the JSON api it might be better to keep the calloc and explicitly free it?
I don't think so; pg_parse_json() will error out quickly, so I don't
see much adva
On Mon, Apr 21, 2025 at 9:30 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Yeah, that would work and will allow to avoid MAP_FIXED and mremap, which are
> questionable from portability point of view. This leaves memfd_create, and I'm
> still not completely clear on it's portability -- it seems
On Tue, Apr 15, 2025 at 11:11 PM Jelte Fennema-Nio wrote:
> On Wed, 16 Apr 2025 at 02:03, Jacob Champion
> wrote:
> > Thank you for saying something; I'd hallucinated that srvoptions was
> > limited to the server owner, and that's not true. It's pg_user_mapping
> > that has the protection.
>
> FW
On 2025-04-21 Mo 7:42 AM, Hayato Kuroda (Fujitsu) wrote:
I also checked PATH/LD_LIBRARY_PATH and they looked correct.
PATH=/home/hayato/builddir/tmp_install//usr/local/pgsql/bin:/home/hayato/builddir/src/test/regress:/usr/local/pgsql/bin/:...
LD_LIBRARY_PATH=/home/hayato/builddir/tmp_install//u
Dear Michael,
> > I also feel just converting lower case is not good. The point seems to
> > locate in
> > the end-of-transaction callback and it accepts invalidation messages. Based
> > on
> the
> > fact, how about "inval-process-invalidation-messages"?
> > 0002 did simple replacements of these
Dear Andres,
Sorry for late response. I have not been reproduced till now and now I do.
When happened, the problem still happens even when another build directory
is introduced.
There might be hidden conditions I have not found yet.
> I can't reproduce this. For me the psql started by pg_regress
On 4/21/25 07:46, Frédéric Yhuel wrote:
I can try to implement Tom's idea if we have a consensus.
v3 attached. Would that do?From 07d331ba0f91b999fcefd12696bfc1eda7e8f20f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?=
Date: Fri, 18 Apr 2025 13:20:52 +0200
Subject: [PA
Hi hackers,
Row-level security is an awesome feature. I was originally won over by
the simple mental model of implicitly adding WHERE clauses to all
queries, and that it generally comes for free when they can be
satisfied by Index Conds.
I've recently helped implement row-level security in a fair
On 4/18/25 03:03, Vinod Sridharan wrote:
> Hello,
> As part of testing this change I believe I found a scenario where the
> parallel build seems to trigger OOMs for larger indexes. Specifically,
> the calls for ginEntryInsert seem to leak memory into
> TopTransactionContext and OOM/crash the out
Hi,
So here's a v4 with the test restored.
>
I tested this patch, it fixes the issue reported. It passes Github CI tests.
> already does that, so the only new assert would be in
> MemoryContextCreate.
+1 for adding the assertion to increase the chances of this bug being
caught by memory cont
> On Thu, Apr 17, 2025 at 07:05:36PM GMT, Ni Ku wrote:
> I also have a related question about how ftruncate() is used in the patch.
> In my testing I also see that when using ftruncate to shrink a shared
> segment, the memory is freed immediately after the call, even if other
> processes still have
> On Fri, Apr 18, 2025 at 10:06:23AM GMT, Konstantin Knizhnik wrote:
> The only drawback is that we are loosing content of shared buffers in case
> of resize. It may be sadly, but not looks like there is no better
> alternative.
No, why would we loose the content? If we do mremap, it will leave th
> On Fri, Apr 18, 2025 at 09:17:21PM GMT, Thomas Munro wrote:
> I was imagining that you might map some maximum possible size at the
> beginning to reserve the address space permanently, and then adjust
> the virtual memory object's size with ftruncate as required to provide
> backing. Doesn't tha
On Mon, Apr 21, 2025 at 4:02 PM Fujii Masao wrote:
>
>
>
> On 2025/04/21 11:30, jian he wrote:
> > hi.
> > While trying to make the virtual generated column be part of the partition
> > key,
> > I found this bug.
>
> I haven't looked at the patch in detail yet, but when I applied it
> and ran the
On 2025/04/21 11:30, jian he wrote:
hi.
While trying to make the virtual generated column be part of the partition key,
I found this bug.
I haven't looked at the patch in detail yet, but when I applied it
and ran the regression tests with RELCACHE_FORCE_RELEASE and
CATCACHE_FORCE_RELEASE ena
On Mon, Apr 14, 2025 at 12:36:20PM +, Hayato Kuroda (Fujitsu) wrote:
> I also feel just converting lower case is not good. The point seems to locate
> in
> the end-of-transaction callback and it accepts invalidation messages. Based
> on the
> fact, how about "inval-process-invalidation-messag
On Fri, Apr 18, 2025 at 12:22:18PM -0400, Robert Haas wrote:
> I think we could add plain-old zstd compression without really
> tackling this issue, but if we are going to add dictionaries then I
> think we might need to revisit the idea of preventing things from
> leaking out of tables. What I can
47 matches
Mail list logo
