On Sat, Aug 16, 2025 at 4:23 PM Tom Lane wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > On 2025-Aug-16, Kirill Reshke wrote:
> >> After putting some more thought into it, maybe we can implement the
> >> whole thing as contrib extension? This would be the most Postgres-y
> >> way to me.
>
On Tue, Aug 19, 2025 at 2:04 PM Jelte Fennema-Nio wrote:
>
> This is now deployed to production. Please let me know if some
> behaviour got broken or styling looks weird.
I found the font difficult to read, like it's not rendering smoothly
on my system. While the text looked smaller, I had to zoo
This patch only addresses the plan cache release for plpgsql (the procedural
language) and does not cover SQL functions.
Since the src/backend/utils/cache/funccache.c file was introduced in PostgreSQL
18, I will first upgrade to version 18,
then figure out how to extend the benefit to SQL funct
Have you considered re-creating pg_shdepend from
pg_largeobject_metadata directly instead of having special cases for
dumping it ?
It would also be useful in cases of old (pg_upgraded since before pg
12) databases which might be missing it anyway.
On Thu, Aug 14, 2025 at 5:22 PM Nathan Bossart
Hi Tom,
> On Aug 8, 2025, at 09:29, Tom Lane wrote:
>
> Anyway, I'm not seriously proposing that this should be committed
> as-is. I'm throwing it out there in case anyone else has a good
> idea or feels motivated to push on the problem some more.
Looks like you are looking for someone to work
This thread is a candidate for [0]
[0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
Best regards,
Kirill Reshke
On Thu, 7 Aug 2025 at 14:15, Nazir Bilal Yavuz wrote:
> I have a couple of ideas that I was working on:
> ---
>
> + * However, SIMD optimization cannot be applied in the following
> cases:
> + * - Inside quoted fields, where escape sequences and closing quotes
> + * requ
On 2025-Aug-19, Jelte Fennema-Nio wrote:
> This is now deployed to production. Please let me know if some
> behaviour got broken or styling looks weird.
Hmm, you seem to have changed the main page title from "Commitfests" to
"CommitFests". There is a subjective argument that the uppercase F in
t
Vladlen Popolitov 2025-08-19 08:39:50 wrote:> Hi!
>
> In your example function will be compiled (the tree is created in
the
> memory)
> and executed.
> During execution this function creates a plan for very simple query
1
> and stores it in the cache, than it creates a plan for query 10 and
>
On Tue, Aug 19, 2025 at 4:15 PM Jelte Fennema-Nio wrote:
>
> Now it's set to this much longer fallback string:
>
> system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", "Noto
> Sans", "Liberation Sans", Arial, sans-serif, "Apple Color Emoji",
> "Segoe UI Emoji", "Segoe UI Symbol", "Noto
On Tue, 19 Aug 2025 at 09:31, John Naylor wrote:
> I found the font difficult to read, like it's not rendering smoothly
> on my system. While the text looked smaller, I had to zoom out to 75%
> in my browser to get the whole table to fit on screen -- anyone else?
> (I didn't see font in the list
On Tue, Aug 19, 2025 at 10:55 AM Ajin Cherian wrote:
>
> Attaching patch v7 addressing all the above comments.
>
Thank You for the patches. Please find a few comments:
1)
We are not resetting 'slot_persistence_pending' to false anywhere. So
once it hits the flow which sets it to true, it will ne
On Tue, Aug 19, 2025 at 10:26:22AM +, Hayato Kuroda (Fujitsu) wrote:
> I added a first version of the test. It could work on my env (Linux).
You could also validate that using the CI, assuming that you have a
cloned repo on github with the CI enabled. See src/tools/ci/README.
I use that a lot
On 8/19/25 11:14, Kirill Reshke wrote:
> This thread is a candidate for [0]
>
>
> [0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items>
>
Added, with Alexander as an owner (assuming it really is caused by
commit bc22dc0e0d.
regards
-
Hi,
On Thu, 14 Aug 2025 at 18:00, KAZAR Ayoub wrote:
>> Thanks for running that benchmark! Would you mind sharing a reproducer
>> for the regression you observed?
>
> Of course, I attached the sql to generate the text and csv test files.
> If having a 1/3 of line length of special characters can
On Tue Aug 19, 2025 at 12:57 AM -03, Daniil Davydov wrote:
>> I think that this definition is correct, but IIUC the tail can still
>> have notifications with xid's that were already truncated by vacuum
>> freeze. When the LISTEN is executed, we first loop through the
>> notification queue to try to
On Tue, 19 Aug 2025 at 11:31, Álvaro Herrera wrote:
>
> On 2025-Aug-19, Jelte Fennema-Nio wrote:
>
> > This is now deployed to production. Please let me know if some
> > behaviour got broken or styling looks weird.
>
> Hmm, you seem to have changed the main page title from "Commitfests" to
> "Comm
Hi
,
> While the text looked smaller, I had to zoom out to 75%
> in my browser to get the whole table to fit on screen -- anyone else?
> (I didn't see font in the list of changes...)
Same here (Firefox 141, Ubuntu 24.04). I had to scale the page to 90%.
It doesn't bother me too much - just wante
> I added a first version of the test. It could work on my env (Linux).
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On Tue, 19 Aug 2025 at 12:06, Jelte Fennema-Nio wrote:
> On Tue, 19 Aug 2025 at 11:31, Álvaro Herrera wrote:
> >
> > On 2025-Aug-19, Jelte Fennema-Nio wrote:
> >
> > > This is now deployed to production. Please let me know if some
> > > behaviour got broken or styling looks weird.
> >
> > Hmm, y
On 7/29/25 20:24, Tomas Vondra wrote:
> Hi!
>
> So, what should we do with the PG18 open item? We (the RMT team) would
> like to know if we shall keep the checksums enabled by default, and if
> there's something that still needs to be done for PG18.
>
> We don't have a strong opinion either way,
On 2025-Aug-16, Robert Treat wrote:
> On Tue, Aug 5, 2025 at 4:59 AM Antonin Houska wrote:
> > Now that we want to cover the CLUSTER/VACUUM FULL completely, I've checked
> > the
> > options of VACUUM FULL. I found two items not supported by REPACK (but also
> > not supported by by CLUSTER): ANA
On 2025-Aug-16, Robert Treat wrote:
> In the v18 patch, the docs say that repack doesn't remember the index,
> but it seems we are still calling mark_index_clustered, so I think the
> above is true but we need to update the docs(?).
Yes, the docs are obsolete on this point, I'm in the process of
On Mon, 18 Aug 2025 at 02:25, Kir Shatrov wrote:
> I'd like to propose a backward-compatible extension to the PostgreSQL
> Frontend/Backend Protocol that would allow servers to send command metadata
> back to clients alongside query results.
I think at least one of your goals for the feature ma
Dear Michael,
> You could also validate that using the CI, assuming that you have a
> cloned repo on github with the CI enabled. See src/tools/ci/README.
> I use that a lot with local branches for pre-commit validations where
> things could break across the board.
I have run the tests on my CI a
10.08.2025 08:45, Kirill Reshke пишет:
> On Sun, 10 Aug 2025 at 01:55, Aleksander Alekseev
> wrote:
>> For this reason we have PageHeaderData.pd_lsn for instance - to make sure
>> pages are evicted only *after* the record that changed it is written
>> to disk (because WAL records can't be applied
09.08.2025 22:54, Kirill Reshke пишет:
> On Thu, 7 Aug 2025 at 21:36, Aleksander Alekseev
> wrote:
>
>> Perhaps there was a good
>> reason to update the VM *before* creating WAL records I'm unaware of.
>
> Looks like 503c730 intentionally does it this way; however, I have not
> yet fully underst
When a function or stored procedure is created, called, and then dropped,
the resulting CachedPlan is never released and can only be freed by exiting the
session.
Meanwhile, if you create another function or stored procedure with the same
name and parameters, and then call it,
you'll be able t
So in my opinion, the cached plan will not be reused but will constantly occupy
resources.
regards,
Zeng Man
Man Zeng писал(а) 2025-08-19 11:28:
So in my opinion, the cached plan will not be reused but will
constantly occupy resources.
regards,
Zeng Man
Hi!
In your example function will be compiled (the tree is created in the
memory)
and executed.
During execution this function creates a plan fo
On Tue, 19 Aug 2025 at 06:47, Masahiko Sawada wrote:
>
> On Mon, Aug 18, 2025 at 4:21 PM Masahiko Sawada wrote:
> >
> > For example, if a sequence is dropped
> > on the publisher, the subscriber would encounter synchronization
> > failures unless the DROP SEQUENCE is properly applied.
>
> This ex
Hi,
On 2025-08-19 15:56:05 +0300, Yura Sokolov wrote:
> 09.08.2025 22:54, Kirill Reshke пишет:
> > On Thu, 7 Aug 2025 at 21:36, Aleksander Alekseev
> > wrote:
> >
> >> Perhaps there was a good
> >> reason to update the VM *before* creating WAL records I'm unaware of.
> >
> > Looks like 503c730 in
19.08.2025 16:09, Andres Freund пишет:
> Hi,
>
> On 2025-08-19 15:56:05 +0300, Yura Sokolov wrote:
>> 09.08.2025 22:54, Kirill Reshke пишет:
>>> On Thu, 7 Aug 2025 at 21:36, Aleksander Alekseev
>>> wrote:
>>>
Perhaps there was a good
reason to update the VM *before* creating WAL records
On Tue, 19 Aug 2025 at 14:14, Kirill Reshke wrote:
>
> This thread is a candidate for [0]
>
>
> [0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
>
Let me summarize this thread for ease of understanding of what's going on:
Timeline:
1) Andrey Borodin sends a patch (on 6 Aug) claiming
19.08.2025 16:17, Kirill Reshke пишет:
> On Tue, 19 Aug 2025 at 14:14, Kirill Reshke wrote:
>>
>> This thread is a candidate for [0]
>>
>>
>> [0]https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
>>
>
> Let me summarize this thread for ease of understanding of what's going on:
>
> Timelin
On Tue, Aug 19, 2025 at 7:57 PM Jelte Fennema-Nio wrote:
>
> On Tue, 19 Aug 2025 at 12:08, Fujii Masao wrote:
> > I pushed the patch registered in PG19-2 and tried to change its status
> > to Committed by clicking [Change Status] -> [Committed] in its
> > commitfest page [1]. This worked fine unt
On Tue, 19 Aug 2025 at 18:29, Yura Sokolov wrote:
> Latch and ConditionVariable (that uses Latch) are among basic
> synchronization primitives in PostgreSQL.
Sure
> Therefore they have to work correctly in any place: in critical section, in
> wal logging, etc.
No. Before bc22dc0e0ddc2dcb6043a
Hi,
On 2025-08-19 09:20:23 +0900, Michael Paquier wrote:
> On Mon, Aug 18, 2025 at 03:10:42PM -0500, Sami Imseih wrote:
> > I agree, but I think it's time to start thinking about splitting
> > pg_stat_statements into multiple functions. This was recently
> > discussed [0]
>
> Yes, no idea for oth
>
>
> I have committed the part that adds a link to the bki documentation.
>
Thnx.
That's good enough for me for now.
hi.
should UPDATE statement need to verify that the domain value is satisfied with
invalid domain constraints?
Álvaro Herrera already mentioned this in [1], but I just want to confirm it.
drop table if exists dt1;
drop domain if exists d1;
create domain d1 as int;
create table dt1(i int, c d1);
i
Chao Li writes:
>> On Aug 19, 2025, at 14:24, Michael Paquier wrote:
>> <0001-Replace-uses-of-long-by-uint64-in-dynahash.c-and-hse.patch>
> There are already pg_nextpower2_64() and pg_nextpower2_32() in pg_bitutils.h,
> feels like the new replacement functions are duplicate to the existing ones
On Wed, Aug 20, 2025 at 2:57 AM Andres Freund wrote:
> On 2025-08-20 02:54:09 +1200, Thomas Munro wrote:
> > > On linux - the primary OS with OOM killer troubles - I'm pretty sure'll
> > > lwlock
> > > waiters would get killed due to the postmaster death signal we've
> > > configured
> > > (c.f.
Hi,
On 2025-08-20 03:19:38 +1200, Thomas Munro wrote:
> On Wed, Aug 20, 2025 at 2:57 AM Andres Freund wrote:
> > On 2025-08-20 02:54:09 +1200, Thomas Munro wrote:
> > > > On linux - the primary OS with OOM killer troubles - I'm pretty sure'll
> > > > lwlock
> > > > waiters would get killed due t
Hi there!
Recently I noticed a performance issue on temporary relation. The issue will
happened on
ON COMMIT DELETE temporary relations. If one session only create a few
temporary relations,
well, it's fine. But if one session creates plenty of ON COMMIT DELETE kind
temporary relations,
say 3,0
"=?utf-8?B?56ug5pmo5pum?=" writes:
> I agree the application is not well designed for PostgreSQL because it was
> migrated
> from Oracle, and may not do such optimization. But back to this issue, even
> though
> we only create 10 temporary relations, it will cause 10 truncates on every
> transa
I've been working on planner extensibility for some time now, and am
still not quite ready to make a full-fledged proposal, but see
partially-fledged proposals here and here:
http://postgr.es/m/CA+TgmoZY+baV-T-5ifDn6P=L=av-vkvbrpmi0tqkceq-5fi...@mail.gmail.com
http://postgr.es/m/CA+TgmoZxQO8svE_vt
"=?utf-8?B?56ug5pmo5pum?=" writes:
> Recently I noticed a performance issue on temporary relation. The issue will
> happened on
> ON COMMIT DELETE temporary relations. If one session only create a few
> temporary relations,
> well, it's fine. But if one session creates plenty of ON COMMIT DELETE
On Wed, Aug 13, 2025 at 9:56 AM Japin Li wrote:
>
> In commit 2633dae2e, I standardized the LSN formatting for log messages using
> zero-padding. However, I mistakenly changed the snapshot file name[1].
>
> I'd like to standardize the LSN-based filename. What's your feedback on this?
Thanks for
On 2025-Aug-19, Chao Li wrote:
> Hi John,
>
> Let me explain the Makefile patch in this separate thread, as this is generic
> to all maps.
>
> Let’s not use gb18030 as an example, instead, using utf8_and_win.
>
> When any of the win-related map file changes, it suppose to automatically
> rebu
On Mon, Aug 18, 2025 at 04:10:38PM -0500, Nathan Bossart wrote:
> Attached is a patch to fix $subject, which appears to be the result of
> commit bb952c8c8b.
Committed.
--
nathan
> I do not think this is something we ought to consider. It might help
> certain corner use-cases, but it's probably a net loss for most.
> In particular, I don't think that creating thousands of temp tables in
> a session but then touching only a few of them in any one transaction
> is a very pla
Aleksander Alekseev writes:
>> While the text looked smaller, I had to zoom out to 75%
>> in my browser to get the whole table to fit on screen -- anyone else?
>> (I didn't see font in the list of changes...)
> Same here (Firefox 141, Ubuntu 24.04). I had to scale the page to 90%.
For me, with
Hi,
On 2025-08-19 02:13:43 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Aug 19, 2025 at 4:52 AM Tom Lane wrote:
> >> But I'm of the opinion that proc_exit
> >> is the wrong thing to use after seeing postmaster death, critical
> >> section or no. We should assume that system integri
On Wed, Aug 20, 2025 at 1:56 AM Andres Freund wrote:
> On 2025-08-19 02:13:43 -0400, Tom Lane wrote:
> > > Then wouldn't backends blocked in LWLockAcquire(x) hang forever, after
> > > someone who holds x calls _exit()?
> >
> > If someone who holds x is killed by (say) the OOM killer, how do
> > we
On Tue, Aug 19, 2025 at 8:45 AM 章晨曦 wrote:
> > I do not think this is something we ought to consider. It might help
> > certain corner use-cases, but it's probably a net loss for most.
> > In particular, I don't think that creating thousands of temp tables in
> > a session but then touching only
"=?utf-8?B?56ug5pmo5pum?=" writes:
> I think you misunderstand Man's meaning. In Man's example, the func cache
> neither dropped (will cause memory leak) nor reused. So the question here:
> 1. Drop the cache when func dropped
> 2. Keep the cache and reused when func recreate
> I prefer the 2ed sol
On Tue, 19 Aug 2025 at 21:16, Yura Sokolov wrote:
>
> That is not true.
> elog(PANIC) doesn't clear LWLocks. And XLogWrite, which is could be called
> from AdvanceXLInsertBuffer, may call elog(PANIC) from several places.
>
> It doesn't lead to any error, because usually postmaster is alive and it
> [ shrug... ] If you create an ON COMMIT DELETE temp table, you
> are explicitly asking for a truncation to happen at every commit.
> I don't think you have much room to beef about the fact that one
> happens.
Yes. ON COMMIT DELETE temp table will be truncated at every commit.
But if we can cont
On Tue, 19 Aug 2025 at 21:16, Yura Sokolov wrote:
>
>
> `if (CritSectionCount != 0) _exit(2) else proc_exit(1)` in
> WaitEventSetWaitBlock () solves the issue of inconsistency IF POSTMASTER IS
> SIGKILLED, and doesn't lead to any problem, if postmaster is not SIGKILL-ed
> (since postmaster will S
Hi,
On Tue, 19 Aug 2025 at 15:33, Nazir Bilal Yavuz wrote:
>
> I am able to reproduce the regression you mentioned but both
> regressions are %20 on my end. I found that (by experimenting) SIMD
> causes a regression if it advances less than 5 characters.
>
> So, I implemented a small heuristic. I
On Mon, Aug 18, 2025 at 3:40 PM Laurenz Albe wrote:
>
> On Mon, 2025-08-18 at 11:38 +0900, Fujii Masao wrote:
> > Thanks! So I've updated the patch based on my earlier comments.
> > Unless there are objections, I'll commit the attached version to master
> > only.
>
> I am fine with your patch.
T
On Tue, 2025-08-19 at 23:40 +0900, Fujii Masao wrote:
> > > --- a/doc/src/sgml/ref/vacuumdb.sgml
> > > +++ b/doc/src/sgml/ref/vacuumdb.sgml
> > > @@ -397,6 +397,15 @@ PostgreSQL documentation
> > > Multiple tables can be vacuumed by writing multiple
> > > -t switches.
> > >
19.08.2025 16:43, Kirill Reshke пишет:
> On Tue, 19 Aug 2025 at 18:29, Yura Sokolov wrote:
>
>
>> Latch and ConditionVariable (that uses Latch) are among basic
>> synchronization primitives in PostgreSQL.
>
> Sure
>
>> Therefore they have to work correctly in any place: in critical section, in
Folks,
Last time I wrote a C extension for PostgreSQL it was easy enough to
write, debug and test the C functions separately as a terminal
application before dropping main() into a #ifdef DEBUG to compile the
extension with prescribed make command invoking PGXS. To get VSCode
C/C++ Intellisen
>> It is unfair to add a performance penalty to everyone just because some
>> people write bad code. I concur that adding complexity to the system to
>> gracefully handle this corner-case doesn't seem justified. A use case
>> description, not mere existence, is needed to provide such justificatio
On Sat, Aug 16, 2025 at 09:34:03PM +0200, Daniel Gustafsson wrote:
> Attached is a rebase on top of the func.sgml changes which caused this to no
> longer apply.
>
> This version is also substantially updated with a new injection point based
> test suite, fixed a few bugs (found by said test suite
Hi,
On 2025-08-20 02:54:09 +1200, Thomas Munro wrote:
> > On linux - the primary OS with OOM killer troubles - I'm pretty sure'll
> > lwlock
> > waiters would get killed due to the postmaster death signal we've configured
> > (c.f. PostmasterDeathSignalInit()).
>
> No, that has a handler that ju
"David G. Johnston" writes:
> On Tue, Aug 19, 2025 at 8:45 AM 章晨曦 wrote:
>> Acturely, we just facing such problem in some real systems. More than 3,700
>> temporary tables created! I accept such case is not that common, but it
>> does exist.
> It is unfair to add a performance penalty to everyon
On Tue, 19 Aug 2025 at 20:24, Andres Freund wrote:
>
> Hi,
>
> On 2025-08-20 03:19:38 +1200, Thomas Munro wrote:
> > On Wed, Aug 20, 2025 at 2:57 AM Andres Freund wrote:
> > > On 2025-08-20 02:54:09 +1200, Thomas Munro wrote:
> > > > > On linux - the primary OS with OOM killer troubles - I'm pret
On 8/17/25 19:30, Peter Geoghegan wrote:
> On Thu, Aug 14, 2025 at 10:12 PM Peter Geoghegan wrote:
>> As far as I know, we only have the following unambiguous performance
>> regressions (that clearly need to be fixed):
>>
>> 1. This issue.
>>
>> 2. There's about a 3% loss of throughput on pgbench
Robert Haas writes:
> But that still requires the extension to do a lot of bookkeeping just
> for the privilege of storing some per-query private state, and it
> seems to me that you might well want to store some private state
> per-RelOptInfo or possibly per-PlannerInfo, which seems to require an
On Tue, Aug 19, 2025 at 08:09:53AM +, Bertrand Drouvot wrote:
> On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
>> > (or some other shmem-based
>> > data structure we have yet to introduce, like a dslist/dsarray).
>>
>> This will be an interesting API to invest time in, if there c
On Tue, 19 Aug 2025 at 16:27, Tom Lane wrote:
> For me, with Safari on macOS, the font does look a bit different but
> not objectionably so. But I too notice that the tables of patches
> seem significantly wider than before. If I zoom out enough to fit
> the whole table width in my usual browser
On Mon, Aug 18, 2025 at 11:55 AM Fujii Masao wrote:
>
> On Fri, Aug 15, 2025 at 1:46 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Fujii-san,
> >
> > Thanks for updating the patch. Your patches look good to me.
>
> Thanks for the review! Unless there are objections, I'll commit these
> two pat
On Fri, Aug 8, 2025 at 4:20 PM Jelte Fennema-Nio wrote:
>
> Thanks to the Claude Code AI tool I was able to get some boring
> cleanup done on the CF app in not that much time. I'll release all of
> it on August 19th.
Thanks for your continued work on improving the commitfest app!
I pushed the pa
Dear Michael, Paul, Mutaamba,
> FWIW, I had my doubts at the beginning on the thread about the
> use-case, but after re-reading the whole thing I am going to side with
> Robert's opinion that if a fix to authorize some of the operations is
> simple, then let's just authorize the case(s) and have t
On Fri, 8 Aug 2025 at 09:19, Jelte Fennema-Nio wrote:
>
> Thanks to the Claude Code AI tool I was able to get some boring
> cleanup done on the CF app in not that much time. I'll release all of
> it on August 19th.
>
> List of the changes:
> - Update to Bootstrap 5 for more modern visual look and
On Mon, Aug 11, 2025 at 9:39 AM Jelte Fennema-Nio wrote:
>
> On Fri, 8 Aug 2025 at 11:55, Álvaro Herrera wrote:
> > Nice stuff.
...
> > Two minor comments: the tags in the patch page
> > https://commitfest-test.postgresql.org/patch/5501/
> > are not clickable, so I can't go to other patches conta
On 09.07.25 01:28, Michael Paquier wrote:
On Tue, Jul 08, 2025 at 05:40:39PM +0300, Florents Tselai wrote:
On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut wrote:
+
+Below are some checklists for common scenarios.
+
+## Adding a New Built-in SQL Command
+
+1. Implement the function in C and pl
> On Aug 19, 2025, at 15:03, Jelte Fennema-Nio wrote:
>>
>
> This is now deployed to production. Please let me know if some
> behaviour got broken or styling looks weird.
The new UI looks nicer.
But I now aways get “Error 503 Backend fetch failed” when I click on any email
link or attachm
On Tue, 19 Aug 2025 at 09:18, Chao Li wrote:
> But I now aways get “Error 503 Backend fetch failed” when I click on any
> email link or attachment link.
Seems the web-archives are having issues. That's unfortunate timing,
but unrelated to the commitfest app deploy.
On Tue, Aug 19, 2025 at 03:18:22PM +0800, Chao Li wrote:
> But I now aways get “Error 503 Backend fetch failed” when I click on
> any email link or attachment link.
That happens from time to time. This is unrelated to the CF app
itself.
--
Michael
signature.asc
Description: PGP signature
https://www.postgresql.org/message-id/flat/tencent_0ba97862026bc74e75238...@qq.com
The new status of this patch is: Needs review
Man Zeng писал(а) 2025-08-19 10:50:
https://www.postgresql.org/message-id/flat/tencent_0ba97862026bc74e75238...@qq.com
The new status of this patch is: Needs review
Hi!
I read from the beginning till this email and did not
find the description what exactly you are going to fix.
Could you pro
Hi,
On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
> > I've been staring at the latest patch for a bit, and I'm a bit concerned
> > at how much complexity it adds.
>
> The complexity is the fact we have to track a dsa_pointer that points
> to an array of dsa_pointers that track the
On Mon, 2025-08-18 at 09:57 -0400, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>
> > I have wanted this MANY times. I've had this as a PG user: I think
> > it's literally the first thing I did when connecting to a Postgres
> > server the first time. Coming from MySQL, I wanted to see the exact
>
Hi,
FWIW I'm +1 on the feature idea, I think it would really allow way better
metrics processing.
On Tue, Aug 19, 2025 at 07:55:10AM +0800, Andy Fan wrote:
> Kir Shatrov writes:
>
> Hi,
>
> > ## Unlocking Greater Extensions
> >
> > Extensions leveraging this metadata protocol could allow to buil
On Tue, 19 Aug 2025 at 12:08, Fujii Masao wrote:
> I pushed the patch registered in PG19-2 and tried to change its status
> to Committed by clicking [Change Status] -> [Committed] in its
> commitfest page [1]. This worked fine until yesterday, but starting
> today, nothing happens when I click it.
On Tue, 19 Aug 2025 at 10:25, Ajin Cherian wrote:
>
> Attaching patch v7 addressing all the above comments.
Looks like this thread is not attached to any commitfest entry?
If so, can you please create one[0]? This will be beneficial for
thread, both simplifying patch review and (possibly) incre
On 2025-Aug-19, Jelte Fennema-Nio wrote:
> Applied and deployed your patch to make the monitoring happy.
Many thanks! It is indeed happier.
> Could you add me to whatever list is necessary for me to receive these
> notifications too?
Hmm, I don't know that I can do that. It's kinda hardcoded
Hi,
On 2025-08-19 12:29:14 -0500, Nathan Bossart wrote:
> On Tue, Aug 19, 2025 at 08:09:53AM +, Bertrand Drouvot wrote:
> > On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
> >> > (or some other shmem-based
> >> > data structure we have yet to introduce, like a dslist/dsarray).
> >
Kirill Reshke writes:
> On Tue, 19 Aug 2025 at 21:16, Yura Sokolov wrote:
>> `if (CritSectionCount != 0) _exit(2) else proc_exit(1)` in
>> WaitEventSetWaitBlock () solves the issue of inconsistency IF POSTMASTER IS
>> SIGKILLED, and doesn't lead to any problem, if postmaster is not SIGKILL-ed
>>
On Mon, Aug 18, 2025 at 5:14 PM Matheus Alcantara
wrote:
>
> On Wed Aug 13, 2025 at 4:29 PM -03, Daniil Davydov wrote:
> > Hi,
> >
> > On Mon, Aug 11, 2025 at 8:41 PM Matheus Alcantara
> > wrote:
> >>
> >> On Wed Aug 6, 2025 at 7:44 AM -03, Álvaro Herrera wrote:
> >> >> My questions:
> >> >>
> >>
Hi,
On 2025-08-19 13:31:35 -0500, Nathan Bossart wrote:
> On Tue, Aug 19, 2025 at 02:06:50PM -0400, Andres Freund wrote:
> > Possibly stupid question - is it really worth having a dynamic structure
> > here?
> > The number of tranches is strictly bound, it seems like it'd be simpler to
> > have a
On Tue, Aug 19, 2025 at 1:23 PM Tomas Vondra wrote:
> Thanks for investigating this. I think it's the right direction - simple
> OLTP queries should not be paying for building read_stream when there's
> little chance of benefit.
>
> Unfortunately, this seems to be causing regressions, both compare
Kirill Reshke writes:
> On Tue, 19 Aug 2025 at 10:32, Thomas Munro wrote:
>> Any idea involving deferring the handling of PM death from here
>> doesn't seem right: you'd keep waiting for the CV, but the backend
>> that would wake you might have exited.
Yeah. Taking the check for PM death out of
Andrey Borodin writes:
> I believe there is a bug with PageIsAllVisible(page) &&
> visibilitymap_clear(). But I cannot prove it with an injection point test.
> Because injections points rely on CondVar, that per se creates corruption in
> critical section. So I'm reading this discussion and won
On Thu, 14 Aug 2025 at 15:10, Heikki Linnakangas wrote:
> Here's a new set of patches, to disconnect on OOM instead of hanging or
> silently discarding messages:
Code looks good. Som small nitpicks though.
This change seems unnecessary, i.e. free(NULL) is a no-op
-free(svname);
+
> Nathan Bossart writes:
> > On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote:
> >> Sure, but we don't need to support a large number of tranches. Just make
> >> it,
> >> idk, 128 entries long. Adding a dynamically allocated dsm to every server
> >> seems like a waste - ever shared m
Nathan Bossart writes:
> On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote:
>> Sure, but we don't need to support a large number of tranches. Just make it,
>> idk, 128 entries long. Adding a dynamically allocated dsm to every server
>> seems like a waste - ever shared mapping makes for
1 - 100 of 161 matches
Mail list logo
