On 25/09/2025 7:35 AM, Michael Paquier wrote:
On Mon, Sep 22, 2025 at 07:44:18PM +0300, Константин Книжник wrote:
Attached please find rebased version of the patch with fixed mistypings.
I have looked at v3.
- leftpage = PageGetTempPage(origpage);
+ leftpage = leftpage_buf.data;
+ memcp
On Wed, Sep 24, 2025 at 07:48:32AM +, Bertrand Drouvot wrote:
> On Wed, Sep 03, 2025 at 07:33:37AM +, Bertrand Drouvot wrote:
>> As far the ordering concern for v1, what about:
>>
>> - let backend kind enum defined as 6
>> - move the backend flush outside of the loop in pgstat_report_stat(
On Thu, Sep 25, 2025 at 09:41:00AM +0300, Konstantin Knizhnik wrote:
> Sorry, I have attached wrong patch.
Thanks, I was confused for a couple of minutes.
+/*
+ * Now we are in critical section and it is not needed to maintain
temporary
+ * copy of right page in the local memory. We
On Thu, Sep 4, 2025 at 8:00 PM Álvaro Herrera wrote:
>
> On 2025-Sep-04, jian he wrote:
>
> > @@ -3093,6 +3115,16 @@ AddRelationNotNullConstraints(Relation rel, List
> > *constraints,
> > conname = other->name;
> >
> > inhcount++
On Wed, 17 Sept 2025 at 16:24, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shlok,
>
> Thanks for creating the patch. Personally I prefer approach2; approach1 cannot
> indicate the current status of synchronization, it just shows the history.
> I feel approach2 has more information than approach1.
>
I
On 2025-09-18 Th 6:53 PM, Álvaro Herrera wrote:
I highly doubt that anybody is going to be confused in the slightest
about what the REPACK command does, or that they would start to think
about when did they PACK anything before. That sort of argument seems
entirely artificial, and that is not h
On Tue, Sep 23, 2025 at 12:19 PM Amit Kapila wrote:
>
> On Wed, Sep 17, 2025 at 4:19 PM Vitaly Davydov
> wrote:
> >
> > [1] 0001-Fix-invalidation-when-slot-is-created-during-checkpo.patch
> >
>
> - /* Calculate how many segments are kept by slots. */
> - keep = slotsMinReqLSN;
> + /*
> + * Calcu
Re: Daniel Gustafsson
> > In the meantime, I also got the report that postgresql-17 is not
> > failing in that environment, so the problem is new in 18.
>
> That's odd, off the cuff I don't see anything materially different around this
> but I'll do some more digging. It will at least be fixed by
On Wed, Sep 24, 2025 at 08:04:59AM +0700, John Naylor wrote:
> 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(
Hello Michael and Tom,
Thank you for spending time on this!
24.09.2025 13:45, Michael Banck wrote:
btw, the stats test failed in a similar way on hamerkop (Windows Server
2016) once, 35 days ago:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2025-08-19%2013%3A56%3A17
Yes
On 17.09.25 18:26, Jacob Champion wrote:
On Tue, Sep 16, 2025 at 10:21 PM Peter Eisentraut wrote:
I think there is agreement that the PointerIsValid() macro is pretty
useless. This patch proposes to remove it. There have been a few
recent mini-discussions in other threads that appear to supp
On Wed, Sep 24, 2025 at 12:13:34PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> * RangeVarCallbackForReindexIndex() was checking privileges on the table
>> before locking it, so I reversed it in 0002.
>
> Don't we do that intentionally, to make sure someone can't cause DOS
> on a table they
On Wed Sep 24, 2025 at 10:59 AM -03, Arseniy Mukhin wrote:
> Thank you! Speaking of the scenario, my understanding is that it's
> impossible as we hold the global lock, so QueuePosition head should
> always be equal to QUEUE_HEAD when we get into At_AbortNotify(), but
> maybe I'm wrong.
>
Let's see
Hi,
On Wed, Sep 24, 2025 at 03:37:07PM +0530, Ashutosh Bapat wrote:
> On Wed, Sep 24, 2025 at 1:55 PM Bertrand Drouvot
> wrote:
> > Right. But, in the example above, do you consider "skip-empty-xacts" as
> > "core"
> > or "plugin" filtering?
> >
> > It's an option part of the "test_decoding" plu
Hi Oliver,
> On Wed, Sep 24, 2025 at 6:39 AM Tatsuo Ishii wrote:
>
>> I tried to change all "int ignore_nulls;" to "uint8 ignore_nulls;" but
>> gen_node_support.pl dislikes it and complains like:
>>
>> could not handle type "uint8" in struct "FuncCall" field "ignore_nulls"
>>
>>
> uint8 was mis
On Fri, Sep 19, 2025 at 10:58 AM Michael Paquier wrote:
>
> On Thu, Sep 18, 2025 at 05:07:00PM +0530, Dilip Kumar wrote:
> > I think this comment is a side note which is stating that it is
> > possible that while XLogNeedFlush() is deciding that based on the
> > current flush position or min recov
Dear Amit, Vitaly,
> I was thinking some more about this solution. Won't it lead to the
> same problem if ReplicationSlotReserveWal() calls
> ReplicationSlotsComputeRequiredLSN() after the above calculation of
> checkpointer?
Exactly. I verified that in your patch, the invalidation can still happ
Re: Daniel Gustafsson
> It seems a bit restrictive to require the openssl binary which is test-only,
> since we allow building with ssl but without TAP support (which is where the
> openssl binary is used).
Ok, but then the error messages should be better. This was found
because a fellow Debian de
On Tue, Sep 23, 2025 at 2:59 PM shveta malik wrote:
>
> 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
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, so I tried fixing them by adding the
following to the beginning of
On Wed, Sep 24, 2025 at 6:39 AM Tatsuo Ishii wrote:
> I tried to change all "int ignore_nulls;" to "uint8 ignore_nulls;" but
> gen_node_support.pl dislikes it and complains like:
>
> could not handle type "uint8" in struct "FuncCall" field "ignore_nulls"
>
>
uint8 was missing in one place in th
Hi,
On Mon, Sep 22, 2025 at 11:30:00PM +0300, Alexander Lakhin wrote:
> Maybe I was wrong and we can at least categorize these failures -- I hope
> their number is finite, but my point was that it's hardly possible to use
> the information, that fruitcrow gives us, to improve Postgres.
Or, for th
On Tue, Sep 23, 2025 at 5:27 PM Tom Lane wrote:
> What I'm saying is that I'd be much happier with 0003 if it looked
> about like the attached. We do not need a heap of mechanism
> redundantly proving that the planner is getting these things right
> (and potentially containing its own bugs).
Tha
On Wed, Sep 24, 2025 at 12:32 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Tue, Sep 23, 2025 at 04:15:14PM +0530, Ashutosh Bapat wrote:
> > On Tue, Sep 23, 2025 at 12:14 PM Bertrand Drouvot
> > wrote:
> > >
> > > - create a table and use pg_logical_slot_get_changes with
> > > ('skip-empty-xacts', '
> On 23 Sep 2025, at 19:03, Nathan Bossart wrote:
> I've CC'd Tomas and Heikki here in case there is anything they want to add
> or disagree with. Thanks everyone!
And a big Thank you! to the three of you for taking on this important work.
--
Daniel Gustafsson
Todd Lang wrote:
> When creating a collation, in
> https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/pg_locale_icu.c#L461
> it is opening the collator with the tailoring rules supplied. However, it
> has hardcoded the strength level UCOL_DEFAULT_STRENGTH. This has the
On Wed, Sep 24, 2025 at 12:14 PM Ashutosh Sharma wrote:
>
> 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 v
On Wed, Sep 24, 2025 at 09:41:19AM +0200, Michael Banck wrote:
> On Wed, Sep 24, 2025 at 08:31:27AM +0900, Michael Paquier wrote:
> > So yes, this random factor would be annoying in the buildfarm.
>
> How much timer resolution do we require from the system? GNU Mach seems
> to (at least try to) gu
Hi,
On Wed, Sep 24, 2025 at 08:31:27AM +0900, Michael Paquier wrote:
> We've had this exact same issue of a clock going backwards with one of
> the netbsd animals on an older version not supported anymore by
> upstream and that has been kicked out of the buildfarm, as far as I
> recall. This has
Attached is PoC v2, which fully replaces the hash table with radix
tree and passes regression tests.
The architecture is still one of tidbitmap.c having it's own tree of
(fixed length) PagetableEntries. The eventual goal is for vacuum and
tidbitmap to both use TID store in some form, but there are
Hi Richard
> I think the following change fixes this problem.
>
> foreach(l, (List *) parse->havingQual)
> {
> Node *havingclause = (Node *) lfirst(l);
> + Relids having_relids;
>
> if (contain_agg_clause(havingclause) ||
> contain_volatile_funct
On Wed, Sep 24, 2025 at 12:47 PM Ashutosh Bapat
wrote:
>
> On Wed, Sep 24, 2025 at 10:12 AM shveta malik wrote:
> >
> > I tested the flows with
> > a) logical replication slot and get-changes.
> > b) filtered data flows: pub-sub creation with row_filters, 'publish'
> > options. I tried to verify
> On Sep 24, 2025, at 14:42, John Naylor wrote:
>
>
> Sounds good. Were you also interested in seeing if EUC_CN can use the
> same UCM file? That would allow us to get rid of the XML file.
>
Sure, let me take a look.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.hig
On Wed, Sep 24, 2025 at 10:12 AM shveta malik wrote:
>
> I tested the flows with
> a) logical replication slot and get-changes.
> b) filtered data flows: pub-sub creation with row_filters, 'publish'
> options. I tried to verify plugin fields as compared to total_wal*
> fields.
> c) reset flow.
>
>
Hi Peter!
On Wed, 2025-09-24 at 12:46 +1000, Peter Smith wrote:
> 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
> On 24 Sep 2025, at 13:37, Christoph Berg wrote:
>
> Re: Daniel Gustafsson
>> It seems a bit restrictive to require the openssl binary which is test-only,
>> since we allow building with ssl but without TAP support (which is where the
>> openssl binary is used).
>
> Ok, but then the error messa
On Wed, 2025-09-24 at 07:26 -0700, Bharath Rupireddy wrote:
> Right. Reading unflushed WAL buffers for replication was one of the
> motivations. But, in general, WALReadFromBuffers has more benefits
> since it lets WAL buffers act as a cache for reads, avoiding the need
> to re-read WAL from disk f
Hi,
On Wed, Sep 24, 2025 at 11:27 AM Jeff Davis wrote:
>
> On Wed, 2025-09-24 at 07:26 -0700, Bharath Rupireddy wrote:
> > Right. Reading unflushed WAL buffers for replication was one of the
> > motivations. But, in general, WALReadFromBuffers has more benefits
> > since it lets WAL buffers act a
On Wed, Sep 24, 2025 at 12:11 AM Álvaro Herrera wrote:
>
> Hello,
>
>
> > /*
> > - * Check whether the passed slot name is valid and report errors at elevel.
> > + * Check whether the passed slot name is valid and report errors.
> > + *
> > + * When called from a GUC check hook, elevel must be 0.
Hi,
On Mon, Sep 22, 2025 at 8:26 AM 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 des
Dear Amit, Hayato
On Wednesday, September 24, 2025 14:31 MSK, "Hayato Kuroda (Fujitsu)"
wrote:
>> I was thinking some more about this solution. Won't it lead to the
>> same problem if ReplicationSlotReserveWal() calls
>> ReplicationSlotsComputeRequiredLSN() after the above calculation of
>> che
Hi,
On Wed, Sep 24, 2025 at 10:28:46AM -0400, Tom Lane wrote:
> It seems plausible that the execution time of the stats
> test's function-under-test is so short that it sometimes
> doesn't register as more than zero on a machine with poor
> clock resolution. It looks like that test only calls the
On Mon, Mar 10, 2025 at 10:15:19AM -0500, Nathan Bossart wrote:
> On Sun, Mar 09, 2025 at 11:48:05AM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
ReindexIndex() faces this same problem and solves it with some
very complex
On Tue, Sep 23, 2025 at 9:51 AM Chao Li wrote:
>
>
>
> On Sep 23, 2025, at 08:45, Fujii Masao wrote:
>
>
> I noticed the commit message in the patch lists you as "Author: Chao
> Li ",
> but in this discussion you've been using "li.evan.c...@gmail.com",
> which also seems to be the address used in
>
> * The lists of major features [2] and acknowledgments [3] were done
> last-minute and weren't tracked by the RMT. As proposed elsewhere [4], I
> think we should set a deadline of beta{2,3} for these and have the RMT
> track them as open items. That means we'll also need to find volunteers
> r
On Fri, 2025-09-19 at 17:21 -0700, Jeff Davis wrote:
>
> Proposal
>
>
> New builtin case-insensitive collation PG_UNICODE_CI, where the
> ordering semantics are just:
>
>strcmp(CASEFOLD(arg1), CASEFOLD(arg2))
>
> and the character semantics are the same as PG_UNICODE_FAST.
On Wed, Sep 24, 2025 at 1:40 AM Matheus Alcantara
wrote:
>
> 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 ha
> On 24 Sep 2025, at 13:51, Christoph Berg wrote:
>> Do you feel like expanding your patch or should I?
>
> TBH I know very little about how TAP interfaces with the build system,
> so that's better with you.
Looking at this I was reminded that we already handle this by using a fallback
and the
Nathan Bossart writes:
> * RangeVarCallbackForReindexIndex() was checking privileges on the table
> before locking it, so I reversed it in 0002.
Don't we do that intentionally, to make sure someone can't cause DOS
on a table they have no privileges on?
regards, tom lane
> On Sep 24, 2025, at 14:37, Shubham Khanna wrote:
>
>
>
> The attached patch contains the suggested changes.
>
> Thanks and regards,
> Shubham Khanna.
>
1.
```
+ if (dbinfo->made_publication)
+ drop_publication(conn, dbinfo->pubname, dbinfo->dbname,
+
On Thu, 25 Sep 2025 02:19:27 +0900
Fujii Masao wrote:
> On Tue, Sep 23, 2025 at 11:58 AM Rintaro Ikeda
> wrote:
> > I think the issue is a new bug because we have transitioned to CSTATE_ABORT
> > immediately after queries failed, without executing discardUntilSync().
Agreed.
> If so, the fix
On Tue, Sep 23, 2025 at 11:32 PM John Naylor johncnaylo...@gmail.com wrote:
There is no attachment in this thread, so it's not showing up in the
commitfest entry (which will need to be moved to next open
commitfest), so it's not getting CI testing:
https://commitfest.postgresql.org/patch/5726/
N
On Wed, Sep 24, 2025 at 10:59:38AM +0700, John Naylor wrote:
> + if (unlikely(!hex_decode_simd_helper(srcv, &dstv1)))
> + break;
>
> But if you really want to do something here, sprinkling "(un)likely"'s
> here seems like solving the wrong problem (even if they make any
> difference), since the ea
Hi,
On Wed, Sep 24, 2025 at 11:00:00PM +0300, Alexander Lakhin wrote:
> 24.09.2025 18:52, Michael Banck wrote:
> > I did that in the attached, so far my Hurd VM ran the stats test more
> > than 1000 times without a failure with it. I have the loop running till
> > 1, I'll report back tomorrow.
On Thu, 25 Sept 2025 at 13:01, Richard Guo wrote:
> I plan to push this patch soon, unless there are any objections.
What's your confidence levels on the logic now being correct? 100%?
90%? Hopeful?
I've not personally had the time to process the patch and figure out
that this is now safe. It so
Hi Shubham.
On Wed, Sep 24, 2025 at 4:37 PM Shubham Khanna
wrote:
>
...
>
> In the attached patch, I have removed that test case. It’s not really
> valid to combine multiple switches in this way, since using
> --publication together with --clean=publications is effectively the
> same as running p
Dear hackers,
(CC: Alexander, who is an original committer)
While reviewing others, I found $SUBJECT.
Initially the tests inserted 2M tuples twice, and 4464fddf improves to use the
advance_wal().
However, code comments in the test missed to be updated.
PSA the fix patch.
This exists PG17+, which
On Wed, Sep 24, 2025 at 6:43 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Sep 24, 2025 at 03:37:07PM +0530, Ashutosh Bapat wrote:
> > On Wed, Sep 24, 2025 at 1:55 PM Bertrand Drouvot
> > wrote:
> > > Right. But, in the example above, do you consider "skip-empty-xacts" as
> > > "core"
> > > or
On Thu, Sep 25, 2025 at 11:12 AM Yugo Nagata wrote:
> Thank you for your suggestion and updating the patch.
> I'm fine with your version since it is clearer.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
Hello Michael,
25.09.2025 00:22, Michael Banck wrote:
I ran that five times now without a problem, both with and without the
Mach patch I mentioned earlier, and on 32 and 64 bit. Not sure what is
going on here.
Maybe you're running it against REL_15_STABLE, where this test case is
absent... (I
Dear Vitaly,
> I propose to apply this patch and then to think how to resolve this race
> condition, which seems to take place in 18 and master as well.
No, I think this invalidation can't happen in PG18/HEAD.
This is because in CheckpointGuts()->CheckPointReplicationSlots()->
ReplicationSlotsCom
On Tue, Sep 23, 2025 at 11:29 PM Masahiko Sawada wrote:
>
> On Sat, Sep 20, 2025 at 4:59 AM Amit Kapila wrote:
> >
> > On Thu, Sep 18, 2025 at 11:46 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Sep 18, 2025 at 1:33 AM Amit Kapila
> > > wrote:
> > > >
> > > > If we compare conflict_histor
On Tue, Sep 23, 2025 at 12:44 AM Fujii Masao wrote:
>
> On Mon, Sep 22, 2025 at 5:56 PM Mircea Cadariu
> wrote:
> >
> > Hi,
> >
> > On Tue, Sep 16, 2025 at 5:36 PM Fujii Masao wrote:
> >>
> >> Attached is the updated version of the patch.
> >
> >
> > Thanks for the updated version! LGTM.
>
> Th
Michael Banck writes:
> How much timer resolution do we require from the system? GNU Mach seems
> to (at least try to) guarantee that the timer won't go backwards, but it
> does not guarantee (currently) that two consecutive clock_gettime()
> calls will return something different in all cases.
I
Hi Timur.
On Wed, Sep 24, 2025 at 11:47 PM Timur Magomedov
wrote:
...
> >
> > Thanks for the patch! Unfortunately, this is straying into areas with
> > which I'm not familiar, so I'm taking it on faith that these are good
> > changes. For now, I'm happy to merge your patch into the next VCI
> > v
On Wed, Sep 24, 2025 at 07:39:59AM -0400, Greg Burd wrote:
> Thanks Michael, Tom, for the help getting this into shape and in the tree.
By the way, Greg, do you think that we should aim for a state where we
are closer to completion? We have the module up to the point where we
are in pretty good s
Hi Fujii-san,
> On Sep 24, 2025, at 23:57, Fujii Masao wrote:
>
> Got it. I've pushed the patch and used that email address in the commit log.
> Thanks!
Thanks a lot for helping.
Would you mind take a look at the other one-line fix of a function comment:
https://www.postgresql.org/message-id
On Wed, Sep 24, 2025 at 11:37:25AM +0900, Keisuke Kuroda wrote:
> 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).
> If we want to make it clearer
On Mon, Sep 22, 2025 at 07:44:18PM +0300, Константин Книжник wrote:
> Attached please find rebased version of the patch with fixed mistypings.
I have looked at v3.
- leftpage = PageGetTempPage(origpage);
+ leftpage = leftpage_buf.data;
+ memcpy(leftpage, origpage, BLCKSZ);
_bt_pageinit(
On Wed, Sep 24, 2025 at 5:28 PM Ashutosh Bapat
wrote:
>
> On Wed, Sep 24, 2025 at 2:38 PM shveta malik wrote:
> >
> > On Wed, Sep 24, 2025 at 12:47 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Wed, Sep 24, 2025 at 10:12 AM shveta malik
> > > wrote:
> > > >
> > > > I tested the flows with
> > >
On Wed, Sep 24, 2025 at 8:11 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Sep 24, 2025 at 05:28:44PM +0530, Ashutosh Bapat wrote:
> > On Wed, Sep 24, 2025 at 2:38 PM shveta malik wrote:
> > >
> > > On Wed, Sep 24, 2025 at 12:47 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Wed, Sep 24, 202
On Thu, Sep 25, 2025 at 11:17 AM Yugo Nagata wrote:
>
> On Thu, 25 Sep 2025 11:09:40 +0900
> Yugo Nagata wrote:
>
> > On Thu, 25 Sep 2025 02:19:27 +0900
> > Fujii Masao wrote:
> >
> > > On Tue, Sep 23, 2025 at 11:58 AM Rintaro Ikeda
> > > wrote:
> > > > I think the issue is a new bug because we
Robert Haas writes:
> Here's a new set of patches. I've added a new 0001 at the beginning to
> fix the bug you identified in SetExplainExtensionState; this will need
> to be back-patched to v18 once the release freeze lifts.
I'm good with 0001, and the release freeze is over, so push that
wheneve
On Thu, Sep 25, 2025 at 11:09 AM Dilip Kumar wrote:
>
> On Sat, Sep 20, 2025 at 5:29 PM Amit Kapila wrote:
> >
> > On Thu, Sep 18, 2025 at 11:46 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Sep 18, 2025 at 1:33 AM Amit Kapila
> > > wrote:
> > > >
> > > > If we compare conflict_history_ta
74 matches
Mail list logo
