Hi,
On 2025-01-16 14:50:57 +0530, Ritu Bhandari wrote:
> Adding to Andy Fan's point above:
>
> If we increase WAL segment size from 16MB to 64MB, initializing the 64MB
> WAL segment inline can cause several seconds of freeze on all write
> transactions when it happens. Writing out a newly zero-fil
On Wed, 2025-01-15 at 13:21 -0800, Jeff Davis wrote:
> I plan to commit 0001 and 0002 soon.
Committed 0001 and 0002.
Upon reviewing the discussion threads, I removed the Unicode "adjust to
Cased" behavior when titlecasing. As Peter pointed out[1], it doesn't
match the documentation or expectation
Hunaid Sohail writes:
> I’ve attached a new patch that addresses comments 2, 3, and 4 from Tomas.
I'm still quite unhappy that this doesn't tolerate trailing
whitespace. That's not how other format patterns work, and it makes
it impossible to round-trip the output of to_char(..., 'RN').
I think
On Fri, 17 Jan 2025 at 21:30, vignesh C wrote:
>
> On Fri, 17 Jan 2025 at 14:00, Sergey Tatarintsev
> wrote:
> >
> > Hi, hackers!
> >
> > I am looking at subscription creation command:
> >
> > CREATE SUBSCRIPTION sub CONNECTION '...' PUBLICATION pub WITH (origin =
> > none, copy_data = on);
> >
>
17.01.2025 23:00, vignesh C пишет:
On Fri, 17 Jan 2025 at 14:00, Sergey Tatarintsev
wrote:
Hi, hackers!
I am looking at subscription creation command:
CREATE SUBSCRIPTION sub CONNECTION '...' PUBLICATION pub WITH (origin =
none, copy_data = on);
For now we log a warning if the publisher ha
On Sat, Jan 18, 2025 at 9:43 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > ISTM Andres tend to use *es_epq_active* in a boolean way,
> > like `if (es_epq_active) then`, but in the code base, all its usages
> > follow pattern `if (es_epq_active == NULL) then`, so I propose to
> > change es_epq_a
Jacob Brazeal writes:
> In bufmgr.c we have the debugging functions PrintBufferDescs
> and PrintPinnedBufs, which are typically hidden behind the flag
> #ifdef NOT_USED. These functions reference the old buf->refcount and
> buf->flags fields, and so they no longer compile. I attached a patch to
>
On Wed, 2025-01-15 at 12:42 -0800, Jeff Davis wrote:
> > Here's v12 after committing a few of the earlier patches.
And here's v14, just a rebase.
> I collected some performance numbers for a worst case on UTF8.
I'm still inlined to think the method table is a good thing to do:
(a) The performan
On Fri, Jan 17, 2025 at 9:53 PM Tom Lane wrote:
> Jacob Brazeal writes:
> > In bufmgr.c we have the debugging functions PrintBufferDescs
> > and PrintPinnedBufs, which are typically hidden behind the flag
> > #ifdef NOT_USED. These functions reference the old buf->refcount and
> > buf->flags fie
Le 17/01/2025 à 19:01, Bruce Momjian a écrit :
On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
So this feature would be like global GUC variables, with permission
control?
+ types and domain type check - holds da
Hi,
I apologize for the late response. I completely missed tracking
updates on this thread.
On Tue, Nov 19, 2024 at 5:28 PM Noah Misch wrote:
>
> On Thu, Oct 03, 2024 at 06:55:47AM -0700, Masahiko Sawada wrote:
> > I've attached PoC patches for the idea Noah proposed. Newly created
> > clusters
On Fri, 2025-01-17 at 16:06 -0800, Jeff Davis wrote:
> Upon reviewing the discussion threads, I removed the Unicode "adjust
> to
> Cased" behavior when titlecasing. As Peter pointed out[1], it doesn't
> match the documentation or expectations for INITCAP().
Forgot to add a link to the discussion.
Hi hackers,
While reviewing the ExecSeqScan optimizations patch[1], I found that
es_epq_active might not be well named, my intuition told me that this
is a boolean field because of the "active" suffix.
es_epq_active was introduced in 27cc7cd, in the original discussion[2],
Tom and Andres discusse
Robert Treat writes:
> suggested diffs attached, let me know if you would like a consolidated patch
Sadly, the cfbot is now confused since it doesn't understand the idea
of an incremental patch. Somebody please post a consolidated patch.
For myself, I'd suggest writing the examples with -X not
Pavel Stehule writes:
> pá 18. 10. 2024 v 22:23 odesílatel Tom Lane napsal:
>> The problem here is that we failed to pass through the result of
>> PG_GET_COLLATION() to text_starts_with. We could do that, certainly,
>> for a couple more lines of code. But it feels like this is getting
>> into d
This is a bug indeed. I tried your patch, but it ends up in a seg fault.
I also see this was raised in another thread [0].
It can be reproduced in a slightly simplified case, using only a
single level partition.
"""
CREATE TABLE bar(id int PRIMARY KEY) PARTITION BY RANGE(id);
CREATE TABLE bar_p0
>
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian
> napsal:
>
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
>
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, a
On Fri, Jan 17, 2025 at 10:45:28AM -0500, Andres Freund wrote:
> I think it is sensible infrastructure and we'll eventually end up using
> it. The cost of having it fairly low. If it were a legacy thing that we
> shouldn't introduce new users for it'd be a different story, but it's the
> opposite.
On Fri, Jan 17, 2025 at 03:24:34PM +0800, Julien Rouhaud wrote:
> The real solution is probably to rely on the new
> pluggable statistic architecture rather than using the hash table / query text
> file.
My own plan was to propose exactly that in the v19 cycle, leaving one
release with this infras
Bruce Momjian:
Now, can people give feedback that they would want
this committed to PostgreSQL?
From a user's perspective: Yes!
I've been waiting for this for a long time and I really hope this can go
through, eventually.
Best,
Wolfgang
Hi,
In bufmgr.c we have the debugging functions PrintBufferDescs
and PrintPinnedBufs, which are typically hidden behind the flag
#ifdef NOT_USED. These functions reference the old buf->refcount and
buf->flags fields, and so they no longer compile. I attached a patch to
use BUF_STATE_GET_REFCOUNT i
Em sex., 17 de jan. de 2025 às 13:01, Bruce Momjian
escreveu:
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, and
c
On Thu, Jan 16, 2025 at 3:18 AM Richard Guo wrote:
> If this t1/t2 join is part of a larger SELECT query, I think the cost
> estimates for the upper join nodes would likely be quite inaccurate.
That's definitely true. However, the question is not whether the
planner has problems today (it definit
> Wait a second, why do we have these here? Aren't they already in
> \dconfig?
\dconfig is generated by querying pg_settings and this
requires a halthy connection. The parameters being proposed with
\conninfo+ are set in libpq by the server [1] and can be retrieved
even if the connection breaks.
Junwang Zhao writes:
> ISTM Andres tend to use *es_epq_active* in a boolean way,
> like `if (es_epq_active) then`, but in the code base, all its usages
> follow pattern `if (es_epq_active == NULL) then`, so I propose to
> change es_epq_active to es_epqstate.
While I didn't especially love "es_epq
Since this patch takes out a lock to read the BufferDesc state, I also need
to release the lock, which I've added to this patch.
On Fri, Jan 17, 2025 at 2:11 PM Jacob Brazeal
wrote:
> Hi,
>
> In bufmgr.c we have the debugging functions PrintBufferDescs
> and PrintPinnedBufs, which are typically
Hi, hackers!
I am looking at subscription creation command:
CREATE SUBSCRIPTION sub CONNECTION '...' PUBLICATION pub WITH (origin =
none, copy_data = on);
For now we log a warning if the publisher has subscribed to the same
table from some other publisher.
However, in case of publication wit
On Wed, Jan 15, 2025 at 1:34 AM Fujii Masao wrote:
>
>
>
> On 2025/01/12 18:27, Ryo Kanbayashi wrote:
> > Thank you for reviewing patch :)
> > The commit log matches with my recognition and has no problem.
>
> Pushed. Thanks!
>
> >>> check_patches.sh -> utility script for testing above two patches
Em sex., 17 de jan. de 2025 às 05:11, Peter Eisentraut
escreveu:
> On 16.01.25 11:23, Ranier Vilela wrote:
> >
> >
> > Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
> > mailto:pe...@eisentraut.org>> escreveu:
> >
> > On 16.01.25 02:12, Ranier Vilela wrote:
> > > Per Coverity.
>
Hi,
Applications often face an "out of memory" condition as they try to fetch
"N rows" from the database.
If N is small, then the execution becomes inefficient due to many
roundtrips.
If N is high, there's a risk that many rows would overflow the client's
memory.
Note: the client can't stop readi
On Tue, 14 Jan 2025 at 18:33, Robert Haas wrote:
> On Mon, Jan 6, 2025 at 3:52 AM Rafia Sabih
> wrote:
> > Now, to overcome this limitation, I have worked on this idea (suggested
> by my colleague Bernd Helmle) of bypassing the cursors. The way it works is
> as follows,
> > there is a new GUC in
On Fri, Jan 17, 2025 at 6:40 AM Tom Lane wrote:
> * The README addition, and the basically identical text in the
> commit message, don't even provide a reason to believe that the
> transformation is correct let alone that it will result in faster
> execution. I don't understand why it's so hard t
Kirill,
cursor does not provide a way to limit the fetch size based on the memory
consumption.
Imagine a table like (id int8, value jsonb).
If we use "fetch 1000", then it might require 1GiB on the client if every
row contains 1MiB json.
If the client plays defensively and goes for "fetch 10", it
On Thu, 2024-10-31 at 22:47 +0100, Michael Banck wrote:
> Even though there has not been a lot of discussion on this, here is a
> rebased patch. I have also added it to the upcoming commitfest.
I had a look at the patch.
> --- a/doc/src/sgml/user-manag.sgml
> +++ b/doc/src/sgml/user-manag.sgml
>
On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> Hi
>
> fix oid collision
What is the purpose of continually posting this patch to the email
lists?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let ur
Hi,
On Wed, Jan 15, 2025 at 11:09:00AM -0600, Sami Imseih wrote:
> > Appart from the above that LGTM.
>
> thanks! I took care of your comments.
Thanks!
> I was not sure
> about the need to cast "double" but as you mention this
> is consistent with other parts of pgstatfuncs.c
Yup.
> v4 attach
On Thu, 16 Jan 2025 at 12:35, Nisha Moond wrote:
>
> On Wed, Jan 15, 2025 at 11:37 AM Shlok Kyal wrote:
> >
> > On Thu, 2 Jan 2025 at 15:57, Nisha Moond wrote:
> > >
> > > On Thu, Jan 2, 2025 at 8:16 AM Peter Smith wrote:
> > > >
> > > > Hi Nisha,
> > > >
> > > > Here are some minor review comm
On 1/16/2025 10:00 PM, Yura Sokolov wrote:
Good day, Zhiguo.
Excuse me, I feel sneaky a bit, but I've started another thread just
about increase of NUM_XLOGINSERT_LOCK, because I can measure its effect
even on my working notebook (it is another one: Ryzen 5825U limited to
@2GHz).
http:/
On 2025/01/17 17:46, Ryo Kanbayashi wrote:
So, will you give creating the patch a try?
Yes. I try to write the patch for regression test of ecpg command
warning and error notice :)
Thanks!
BTW, How should we handle commit fest entry below?
"ecpg command does not warn COPY ... FROM STDIN
On Fri, Jan 17, 2025 at 02:48:29PM +0100, Pavel Stehule wrote:
> Hi
>
> pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal:
>
> On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix oid collision
>
> What is the purpose of continually posting
Hi
pá 17. 1. 2025 v 14:41 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 08:18:20AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix oid collision
>
> What is the purpose of continually posting this patch to the email
> lists?
>
The people still do a review, so I am fixing this patch.
hi.
SELECT * FROM pg_catalog.pg_restore_relation_stats(
'relation', 'public.tenk1_hundred'::regclass,
'version', '18'::integer,
'relpages', '11'::integer,
'reltuples', '1'::real,
'relallvisible', '0'::integer
);
dump and execute the above query generated a warning
WARNI
Hi
pá 17. 1. 2025 v 15:39 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 03:28:55PM +0100, Pavel Stehule wrote:
> > Dne pá 17. 1. 2025 15:16 uživatel Bruce Momjian
> napsal:
> > Is this really something we are considering applying, since it has
> been
> > around for years?
On Fri, Jan 17, 2025 at 04:32:07PM +0100, Pavel Stehule wrote:
> This discussion was around 2017 when I wrote a proposal and I hadn't a feeling
2017 is seven years ago so it would be good to get current feedback on
the desirability of this feature.
> There is one stronger argument for session var
{
"emoji": "🙏",
"version": 1
}
On 09.01.25 15:53, Tom Lane wrote:
Peter Eisentraut writes:
The second patch contemplates raising the minimum required flex version,
but what to?
Meh, let's just rip out the version check. It's no longer very
relevant. Nobody is going to be using anything older than 2.5.35.
While 2.5.35 pro
(I've added Thomas Munro to the thread.)
On Fri, Jan 17, 2025 at 02:00:49PM +0900, Michael Paquier wrote:
> XLogRecGetFullXid() has been introduced in 67b9b3ca3283 back in 2019,
> but as far as I can see this has never been used in the code and this
> is used nowhere in the core code.
>
> I have
> One comment:
>
> + PG_RETURN_FLOAT8(result);\
>
> The "\" indentation looks wrong for this line (was ok in v3).
>
> Regards,
>
Indeed. Corrected in v5
Thanks!
Sami
v5-0001-Track-per-relation-cumulative-time-spent-in-vacuu.patch
Description: Binar
Hi,
On 2025-01-17 14:00:49 +0900, Michael Paquier wrote:
> XLogRecGetFullXid() has been introduced in 67b9b3ca3283 back in 2019,
> but as far as I can see this has never been used in the code and this
> is used nowhere in the core code.
>
> I have looked at Debian's codesearch and also looked at t
On Thu, Oct 10, 2024 at 1:56 AM Shinya Kato
wrote:
> Thank you all for the comments!
> While adding to the documentation is sufficient if users use it
> correctly, users often behave unexpectedly. My intention was to
> implement it in a way that works without issues even if misused.
> However, si
Here are some more patches. This should cover the last sub-topic of
this topic: not passing the yyparse() result via global variables. This
uses techniques that are already in use in some parsers in the tree, for
example cube and jsonpath. The syncrep parser was a bit trickier,
because there
pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> On Fri, Jan 17, 2025 at 04:32:07PM +0100, Pavel Stehule wrote:
> > This discussion was around 2017 when I wrote a proposal and I hadn't a
> feeling
>
> 2017 is seven years ago so it would be good to get current feedback on
> the desirabili
Excuse me, Andres, I've found I've pressed wrong button when I sent this
letter first time, and it was sent only to you. So I'm sending the copy now.
Please, reply to this message with copy of your answer. Your answer is
really valuable to be published in the list.
16.01.2025 18:36, Andres Fr
On Thu, Jan 16, 2025 at 2:02 AM Amit Kapila wrote:
>
> On Wed, Jan 15, 2025 at 2:20 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > In the latest version, we implemented a simpler approach that allows the
> > apply
> > worker to directly advance the oldest_nonremovable_xid if the waiting time
> > excee
On 16.01.25 11:23, Ranier Vilela wrote:
Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
mailto:pe...@eisentraut.org>> escreveu:
On 16.01.25 02:12, Ranier Vilela wrote:
> Per Coverity.
>
> CID 1590024: (CHECKED_RETURN)
> Calling "pg_b64_encode" without checki
On Fri, Jan 17, 2025 at 11:01:41AM -0500, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + t
On Fri, 17 Jan 2025 at 14:00, Sergey Tatarintsev
wrote:
>
> Hi, hackers!
>
> I am looking at subscription creation command:
>
> CREATE SUBSCRIPTION sub CONNECTION '...' PUBLICATION pub WITH (origin =
> none, copy_data = on);
>
> For now we log a warning if the publisher has subscribed to the same
On Tue, 14 Jan 2025 at 13:25, Aleksander Alekseev
wrote:
>
> Thanks. I agree that the proposed error messages look nicer than the
> one I used in v6. Here is the corrected patch.
>
This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
ERRCODE_INVALID_PARAMETER_VALUE, for consistency wit
On Fri, Jan 17, 2025 at 1:43 AM Dilip Kumar wrote:
>
> On Fri, Jan 17, 2025 at 6:37 AM Masahiko Sawada wrote:
>>
>> On Sun, Jan 12, 2025 at 1:34 AM Masahiko Sawada
>> wrote:
>> >
>
>
> IIRC, there was one of the blocker for implementing parallel heap vacuum was
> group locking, have we already
With commit e24d770 in place, I took a closer look at hex_decode(), and I
concluded that doing anything better without intrinsics would likely
require either a huge lookup table or something with complexity rivalling
the instrinsics approach (while also not rivalling its performance). So, I
took a
On Thu, Sep 12, 2024 at 2:41 AM Tatsuo Ishii wrote:
>
> It seems you allow to use IGNORE NULLS for all window functions. If
> the case, you should explicitely stat that in the docs. Otherwise
> users will be confused because;
The latest version restricts it to lag, lead, first_value, last_value,
On Fri, 2025-01-17 at 11:01 -0500, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + types an
I've tested on a PG16, the issue is indeed triggered with the
replication blocked while the conflicting query is stuck in
ClientWrite.
I've cleaned up the tests: I've created a dedicated PgProto
(definitely open to suggestions for a better name...) module
containing all the helpers to send and rec
On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
>
> So this feature would be like global GUC variables, with permission
> control?
>
> + types and domain type check - holds data in binary form - there are not
> conv
> On Fri, Jan 17, 2025 at 11:01:41AM GMT, Bruce Momjian wrote:
> On Fri, Jan 17, 2025 at 04:55:07PM +0100, Pavel Stehule wrote:
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian napsal:
> >
> > So this feature would be like global GUC variables, with permission
> > control?
> >
> > + typ
On Wed, Jan 15, 2025 at 4:43 PM Peter Smith wrote:
>
> On Wed, Jan 15, 2025 at 5:49 PM Amit Kapila wrote:
> >
> > On Wed, Jan 15, 2025 at 3:11 AM Masahiko Sawada
> > wrote:
> > >
> > > It seems we agreed on RBTXN_IS_PREPARED and rbtxn_is_prepared().
> > > Adding 'IS' seems to clarify the transa
On 2025/01/17 18:29, Yuki Seino wrote:
Thank you for your comments.
+ Currently, only lock failures due to NOWAIT are
+ supported. The default is off. Only superusers
This GUC also affects SKIP LOCKED, so that should be documented.
I overlooked it... I have revised the document
Hi,
On 2025-01-17 17:01:53 +0100, Anthonin Bonnefoy wrote:
> I've cleaned up the tests: I've created a dedicated PgProto
> (definitely open to suggestions for a better name...) module
> containing all the helpers to send and receive messages on a raw
> socket in 0001.
Might be worth using it it i
Hi,
On 2025-01-17 13:03:35 -0500, Andres Freund wrote:
> I don't see anything implementing the promotion of ERRORs to FATAL? You're
> preventing the error message being sent to the client, but I don't think that
> causes the connection to be terminated. The pre-existing code doesn't have
> that
Bumping this, because I am genuinely interested if there is a better way to
do this.
I'd really like to know if there is a better way than executing dummy
queries...it feels dirty.
I've seen plenty of extensions not handle query cancellation / exceptions
gracefully. Also seems like something to t
Alexander Pyhalov writes:
> I've rebased patch on master. Tests pass here.
The cfbot still doesn't like it; my guess is that you built without
--with-libxml and so didn't notice the effects on xml.out.
I've looked through the patch briefly and have a few thoughts:
* You cannot use plancache.c l
Hi,
On 2025-01-17 13:03:35 -0500, Andres Freund wrote:
> > Previously, all interrupts except process dying were ignored while a
> > process was blocked writing to a socket. If the connection to the client
> > was broken (no clean FIN nor RST), a process sending results to the
> > client could be s
Thank you for your comments.
+ Currently, only lock failures due to NOWAIT are
+ supported. The default is off. Only
superusers
This GUC also affects SKIP LOCKED, so that should be documented.
I overlooked it... I have revised the document with SKIP LOCKED.
If CollectLockHolders
On Fri, Jan 17, 2025 at 6:37 AM Masahiko Sawada
wrote:
> On Sun, Jan 12, 2025 at 1:34 AM Masahiko Sawada
> wrote:
> >
>
IIRC, there was one of the blocker for implementing parallel heap vacuum
was group locking, have we already resolved that issue or its being
included in this patch set?
--
R
On Wed, Jan 15, 2025 at 7:08 PM Anton A. Melnikov
wrote:
> It was x86 AMD Laptop: HP Probook 455 g7 with AMD Ryzen 7 4700U and 64GB DDR4
> RAM.
> OS: Linux 5.15.0-130-generic #140~20.04.1-Ubuntu SMP Wed Dec 18 21:35:34 UTC
> 2024 x86_64 x86_64 x86_64 GNU/Linux.
>
> ~$ valgrind --version
> valgri
Hi,
On Fri, Jan 17, 2025 at 03:12:36PM +0900, Michael Paquier wrote:
> On Fri, Jan 17, 2025 at 06:06:35AM +, Bertrand Drouvot wrote:
> > On Fri, Jan 17, 2025 at 09:08:02AM +0900, Michael Paquier wrote:
> >> I could tweak that around the beginning of next week with a proposal
> >> of patch. Be
On Fri, 17 Jan 2025 at 02:24, Richard Guo wrote:
>
> It seems that adding ParseNamespaceItems for the OLD or NEW aliases
> may confuse scanNameSpaceForRelid() when searching the table namespace
> for a relation item. Since they contain the same RTE,
> scanNameSpaceForRelid() might mistakenly dete
On Fri, Jan 17, 2025 at 1:37 PM Masahiko Sawada wrote:
>
> On Thu, Jan 16, 2025 at 2:02 AM Amit Kapila wrote:
> >
> > On Wed, Jan 15, 2025 at 2:20 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > In the latest version, we implemented a simpler approach that allows the
> > > apply
> > > worker to
Hi, client can use CURSOR feature to process data in batches. What is the
case where proposed feature solves problem that CURSOR does not?
https://www.postgresql.org/docs/current/plpgsql-cursors.html
On Fri, 17 Jan 2025, 16:08 Vladimir Sitnikov,
wrote:
> Hi,
>
> Applications often face an "out
79 matches
Mail list logo
