On Mon, Jun 19, 2023 at 12:37 PM Amit Kapila wrote:
>
> On Mon, Jun 19, 2023 at 6:50 AM Masahiko Sawada wrote:
> >
> > On Sat, Jun 17, 2023 at 6:45 PM Amit Kapila wrote:
> > >
> > > On Tue, May 16, 2023 at 8:00 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, May 11, 2023 at 5:12 PM Mas
On Wed, Jul 05, 2023 at 06:00:25PM +1200, Thomas Munro wrote:
> If this were my animal and if the hardware couldn't be
> upgraded to a modern distro for technical reasons like a de-supported
> architecture, I would now disable HEAD, or more likely give the whole
> machine a respectful send-off cere
On Thu, Jun 29, 2023 at 10:06:35AM +0300, Heikki Linnakangas wrote:
> The error messages like "failed to change schema dependency for extension"
> don't conform to the usual error message style. "could not change schema
> dependency for extension" would be more conformant. I see that you
> copy-pas
On Wed, Jul 5, 2023 at 2:46 PM Amit Kapila wrote:
>
> On Wed, Jul 5, 2023 at 9:01 AM Peter Smith wrote:
> >
> > Hi. Here are some review comments for this patch.
> >
> > +1 for the patch idea.
> >
> > --
> >
> > I wasn't sure about the code comment adjustments suggested by Amit [1]:
> > "Acco
On Tue, Jul 4, 2023 at 7:15 PM David Rowley wrote:
> On Tue, 4 Jul 2023 at 20:12, Richard Guo wrote:
> > The v4 patch looks good to me (maybe some cosmetic tweaks are still
> > needed for the comments). I think it's now 'Ready for Committer'.
>
> I agree. I went and hit the comments with a larg
Hi,
I have a ROW LEVEL SECURITY policy on the table part of an extension, and
while
dumping the database where that extension is installed, dumps the policy of
that table too even though not dumpling that table .
Here is quick tests, where I have added following SQL to adminpack--1.0.sql
extensio
On Wed, Jul 5, 2023 at 4:29 PM Michael Paquier wrote:
> Thoughts?
I am grateful for all the bug discoveries that these Debian 7 animals
provided in their time, but at this point we're unlikely to learn
things that are useful to our mission from them. It costs our
community time to talk about eac
On Wed, Jul 5, 2023 at 9:01 AM Peter Smith wrote:
>
> Hi. Here are some review comments for this patch.
>
> +1 for the patch idea.
>
> --
>
> I wasn't sure about the code comment adjustments suggested by Amit [1]:
> "Accordingly, the comments atop build_replindex_scan_key(),
> FindUsableIndexF
On 04.07.23 14:14, Heikki Linnakangas wrote:
On 26/06/2023 12:33, Peter Eisentraut wrote:
This is a small code cleanup patch.
Several commands internally assemble command lines to call other
commands. This includes initdb, pg_dumpall, and pg_regress. (Also
pg_ctl, but that is different enough
On Tue, Jul 04, 2023 at 02:40:04PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> Hmm, shouldn't we disallow moving the function to another schema, if the
>> function's schema was originally determined at extension creation time?
>> I'm not sure we really want to allow moving objects of an ext
On Mon, Jul 3, 2023 at 6:32 PM Euler Taveira wrote:
>
> On Mon, Jul 3, 2023, at 7:30 AM, Ashutosh Bapat wrote:
>
> logicalrep_message_type() is used to convert logical message type code
> into name while prepared error context or details. Thus when this
> function is called probably an ERROR is al
Hi all,
After removing --with-openssl from its build of HEAD, snapper has
begun failing in the pg_upgrade path 11->HEAD, because it attempts
pg_upgrade from binaries that have OpenSSL to builds without it:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=snapper&br=HEAD
Using the TAP t
Hi. Here are some review comments for this patch.
+1 for the patch idea.
--
I wasn't sure about the code comment adjustments suggested by Amit [1]:
"Accordingly, the comments atop build_replindex_scan_key(),
FindUsableIndexForReplicaIdentityFull(), IsIndexOnlyOnExpression()
should also be ad
Is there any other comment?
If the patch looks OK, I would like to update its status to ready for
committer in the commitfest.
Thanks!
On 2023/6/16 09:28, YANG Xudong wrote:
Updated the patch based on the comments.
On 2023/6/15 18:30, John Naylor wrote:
On Wed, Jun 14, 2023 at 9:20 AM YAN
On Mon, Jun 19, 2023 at 5:29 PM Peter Smith wrote:
>
> Hi,
>
> Below are my review comments for the PoC patch 0001.
>
> In addition, the patch needed rebasing, and, after I rebased it
> locally in my private environment there were still test failures:
> a) The 'make check' tests fail but only in
On Tue, Jul 04, 2023 at 09:34:33AM +0200, Drouvot, Bertrand wrote:
> Yeah, with "capture" set to "false" then ninja alldocs does not error out
> and wait_event_types.sgml gets generated.
>
> I'll look at the extra options --code and --docs.
+wait_event_types.sgml:
$(top_srcdir)/src/backend/utils
Hi,
As discussed in [1], outputs of --help for some commands fits into 80
columns
per line, while others do not.
Since it seems preferable to have consistent line break policy and some
people
use 80-column terminal, wouldn't it be better to make all commands in 80
columns per line?
Attached
On Sat, Jul 1, 2023 at 6:09 AM Thomas Munro wrote:
>
>
> It should be restricted by role, but I wonder which role it should be.
> Testing for superuser is now out of fashion.
>
as pg_buffercache/pg_buffercache--1.2--1.3.sql. You need pg_maintain
privilege to use pg_buffercache.
The following quer
On Tue, Jul 4, 2023 at 2:54 PM Tomas Vondra
wrote:
> I'm not sure if memory context callbacks are the right way to rely on
> for this purpose. The primary purpose of memory contexts is to track
> memory, so using them for this seems a bit weird.
Yeah, this just kept getting dirtier and dirtier.
Hello!
I propose the attached patch to be applied on the 'master' branch
of PostgreSQL to add GitLab CI automation alongside Cirrus CI in the PostgreSQL
repository.
It is not intended to be a replacement for Cirrus CI, but simply suggestion for
the
PostgreSQL project to host centrally a Gitlab
On Tue, Jul 04, 2023 at 04:09:43PM +0900, Michael Paquier wrote:
> On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote:
>> Sure, feel free. I was planning to look at and play more with it.
>
> Well, done.
For the sake of completeness, as I forgot to send my notes.
+ if (PQsendClose
On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote:
> I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN
> always.
>
> Admittedly having the options make testing different of combinations of old
> and new clients and servers a little easier. But I don't thi
On Wed, Jul 5, 2023 at 10:15 AM Thomas Munro wrote:
> [1] https://cirrus-ci.com/build/5298278007308288
That'll teach me to be impatient. I only waited for compiling to
finish after triggering the optional extra MinGW task before sending
the above email, figuring that the only risk was there, but
On Tue, Jul 4, 2023 at 2:52 AM Tristan Partin wrote:
> The patch looks good to me as well. Happy to rebase my other patch on
> this one.
Thanks. Here is a slightly tidier version. It passes on CI[1]
including the optional extra MinGW64/Meson task, and the
MinGW64/autoconf configure+build that i
On 7/4/23 23:53, Matthias van de Meent wrote:
> On Thu, 8 Jun 2023 at 14:55, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Here's a WIP patch allowing parallel CREATE INDEX for BRIN indexes. The
>> infrastructure (starting workers etc.) is "inspired" by the BTREE code
>> (i.e. copied from that and mas
On 7/4/23 21:25, Soumyadeep Chakraborty wrote:
> Thank you both for reviewing!
>
> On Tue, Jul 4, 2023 at 4:24AM Alvaro Herrera wrote:
>
>> Hmm, yeah, I remember being bit bothered by this repeated
>> initialization. Your patch looks reasonable to me. I would set
>> bistate->bs_rmAccess to NULL
On Thu, 8 Jun 2023 at 14:55, Tomas Vondra wrote:
>
> Hi,
>
> Here's a WIP patch allowing parallel CREATE INDEX for BRIN indexes. The
> infrastructure (starting workers etc.) is "inspired" by the BTREE code
> (i.e. copied from that and massaged a bit to call brin stuff).
Nice work.
> In both case
On Tue, Jul 4, 2023 at 03:31:05PM +0900, Michael Paquier wrote:
> On Thu, May 18, 2023 at 04:49:47PM -0400, Bruce Momjian wrote:
> > I have completed the first draft of the PG 16 release notes. You can
> > see the output here:
> >
> > https://momjian.us/pgsql_docs/release-16.html
> >
> > I
> On 4 Jul 2023, at 20:19, Andrew Dunstan wrote:
> But sadly we're kinda back where we started. fairywren is failing on
> REL_16_STABLE. Before the changes the failure occurred because the test
> script was unable to create the file with a path > 255. Now that we have a
> way to create the fil
Hayato Kuroda (Fujitsu) , 4 Tem 2023 Sal,
08:42 tarihinde şunu yazdı:
> > > But in the later patch the tablesync worker tries to reuse the slot
> > > during the
> > > synchronization, so in this case the application_name should be same as
> > slotname.
> > >
> >
> > Fair enough. I am slightly afra
Thank you both for reviewing!
On Tue, Jul 4, 2023 at 4:24AM Alvaro Herrera wrote:
> Hmm, yeah, I remember being bit bothered by this repeated
> initialization. Your patch looks reasonable to me. I would set
> bistate->bs_rmAccess to NULL in the cleanup callback, just to be sure.
> Also, please a
I put together a rebased version of the patch for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From ee5805dc450f081b77ae3a7df315ceafb6ccc5e1 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson
Date: Mon, 13 Mar 2023 14:46:24 +0100
Subject: [PATCH v4 1/1] pg_upgrade: run all
> On Mon, Jul 03, 2023 at 09:46:11PM -0700, Nathan Bossart wrote:
Thanks for reviewing.
> On Sun, Mar 19, 2023 at 01:27:34PM +0100, Dmitry Dolgov wrote:
> > +If this parameter is on, two queries with an array will get the
> > same
> > +query identifier if the only difference betw
Alvaro Herrera writes:
> Hmm, shouldn't we disallow moving the function to another schema, if the
> function's schema was originally determined at extension creation time?
> I'm not sure we really want to allow moving objects of an extension to a
> different schema.
Why not? I do not believe tha
On Tue, Jul 04, 2023 at 09:48:23AM +0200, Daniel Gustafsson wrote:
>> On 17 Mar 2023, at 10:16, Amit Kapila wrote:
>
>> Few minor comments:
>
> Have you had a chance to address the comments raised by Amit in this thread?
Not yet, sorry.
--
Nathan Bossart
Amazon Web Services: https://aws.amazo
On Tue, Jul 04, 2023 at 09:30:43AM +0200, Daniel Gustafsson wrote:
>> On 4 Apr 2023, at 05:36, Nathan Bossart wrote:
>>
>> I sent this one to the next commitfest and marked it as waiting-on-author
>> and targeted for v17. I'm aiming to have something that addresses the
>> latest feedback ready f
Heikki Linnakangas writes:
> On 03/07/2023 11:48, Daniel Gustafsson wrote:
> On 30 Jun 2023, at 17:22, Tom Lane wrote:
>>> Seems reasonable; the trailing dashes eat a line without adding much.
>> +1
> Pushed a patch to remove the end-guard from the example in the pgindent
> README. And fixed t
Nikhil Benesch writes:
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`. You may not find all of these suggestions to be
> worthwhile.
I found some time today to look at these points.
> 1) `in_quotes` appears to be wholly redundant with `parse_state ==
> ARRAY
On 2023-07-03 Mo 11:18, Andrew Dunstan wrote:
On 2023-07-03 Mo 10:16, Daniel Gustafsson wrote:
On 3 Jul 2023, at 16:12, Andrew Dunstan wrote:
I've pushed a better solution, which creates the file via a short symlink.
Experimentation on fairywren showed this working.
The buildfarm seems a t
On 7/4/23 04:29, Kyotaro Horiguchi wrote:
> At Mon, 3 Jul 2023 15:45:52 +0200, Tomas Vondra
> wrote in
>> So I'm wondering if pg_stat_force_next_flush() is enough - AFAICS this
>> only sets some flag for the *next* pgstat_report_stat() call, but how do
>> we know that happens before the query
On 03/07/2023 11:48, Daniel Gustafsson wrote:
On 30 Jun 2023, at 17:22, Tom Lane wrote:
Seems reasonable; the trailing dashes eat a line without adding much.
+1
Pushed a patch to remove the end-guard from the example in the pgindent
README. And fixed the bogus end-guard in walsender.c.
On 2023-Jul-04, Michael Paquier wrote:
> On Mon, Jul 03, 2023 at 07:46:27PM +0200, Alvaro Herrera wrote:
> > Perhaps we could have autovacuum check for it, and do it
> > separately of vacuum proper.)
>
> Being able to reuse some of the worker/launcher parts from autovacuum
> could make things ea
On 2023-Jun-29, Heikki Linnakangas wrote:
> I can hit the above error with the attached test case. That seems wrong,
> although I don't know if it means that the check is wrong or it exposed a
> long-standing bug.
> +CREATE SCHEMA test_func_dep1;
> +CREATE SCHEMA test_func_dep2;
> +CREATE EXTENSI
> On 21 Feb 2023, at 15:50, Heikki Linnakangas wrote:
>
> llvm_release_context() calls llvm_enter_fatal_on_oom(), but it never calls
> llvm_leave_fatal_on_oom(). Isn't that a clear leak?
Not sure how much of a leak it is since IIUC LLVM just stores a function
pointer to our error handler, but I
On 03/07/2023 15:59, Daniel Gustafsson wrote:
This patch required a trivial rebase after conflicting with bfcf1b3480 so I've
attached a v2 to get the CFBot to run this.
Thank you! Pushed to all supported branches. (Without forgetting the new
REL_16_STABLE :-D ).
--
Heikki Linnakangas
Neon (h
On 01.07.23 00:21, Tomas Vondra wrote:
Right, that's the dance we do to protect against torn pages. But Andres
suggested that if you have modern storage and configure it correctly,
writing with 4kB pages would be atomic. So we wouldn't need to do this
FPI stuff, eliminating pretty significant sou
On Mon, 3 Jul 2023 at 17:13, Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Mon, 3 Jul 2023 at 20:06, Dave Cramer wrote:
> >
> > Greetings,
> >
> > For ISO and German dates the order DMY is completely ignored on output
> but used for input.
> >
> > test=# set datestyle to 'ISO,
Nathan,
On Mon, Jul 3, 2023 at 8:12 PM Nathan Bossart
wrote:
> On Mon, Jul 03, 2023 at 06:00:12PM -0700, Yurii Rashkovskii wrote:
> > Great, thank you! The reason I was leaving the other constant in place to
> > make upgrading extensions trivial (so that they don't need to adjust for
> > this),
Hi,
> Thanks, here's a fixed version. (ResourceOwner resource release
> callbacks mustn't call ResourceOwnerForget anymore, but AbortBufferIO
> was still doing that)
I believe v15 is ready to be merged. I suggest we merge it early in
the PG17 release cycle.
--
Best regards,
Aleksander Alekseev
On 31/03/2023 10:59, Greg Stark wrote:
IIRC I put a variable labeled a "GUC" but forgot to actually make it a
GUC. But I'm thinking of maybe removing that variable since I don't
see much of a use case for controlling this manually. I *think* ALPN
is supported by all the versions of OpenSSL we sup
On Mon, Jun 26, 2023 at 8:35 PM Tomas Vondra
wrote:
> On 6/26/23 15:18, Ashutosh Bapat wrote:
> > I will look at 0004 next.
> >
>
> OK
0004- is quite large. I think if we split this into two or even three
1. publication and
subscription catalog handling 2. built-in replication protocol changes,
> On 8 Feb 2023, at 16:57, Tom Lane wrote:
> I do not think this proposal is going anywhere as-written.
Reading this thread, it seems there is concensus against this proposal in its
current form, and no updated patch has been presented, so I will mark this as
Returned with Feedback. Please feel
On 07.06.23 10:19, Daniel Gustafsson wrote:
Unlike for the main regression tests, I didn't write a fipshash() wrapper here,
because that would have been too repetitive and wouldn't really save much here.
In some cases it was easier to remove one layer of indirection by changing
column types f
> On 4 Jul 2023, at 13:59, Heikki Linnakangas wrote:
> On 08/03/2023 00:05, Daniel Gustafsson wrote:
>> If we are going to continue using this for reading $stuff from pipes, maybe
>> we
>> should think about presenting a nicer API which removes that risk? Returning
>> an allocated buffer which
> On 8 May 2023, at 09:10, Peter Eisentraut
> wrote:
>
> On 03.05.23 23:02, Paul Jungwirth wrote:
>> Thank you again for the review. Here is a patch with most of your feedback
>> addressed. Sorry it has taken so long! These patches are rebased up to
>> 1ab763fc22adc88e5d779817e7b42b25a9dd7c9e
> On 28 Mar 2023, at 20:55, Gregory Stark (as CFM) wrote:
>
> It looks like this remaining work isn't going to happen this CF and
> therefore this release. There hasn't been an update since January when
> Dean Rasheed posted a review.
>
> Unless there's any updates soon I'll move this on to the
On 26/06/2023 12:33, Peter Eisentraut wrote:
This is a small code cleanup patch.
Several commands internally assemble command lines to call other
commands. This includes initdb, pg_dumpall, and pg_regress. (Also
pg_ctl, but that is different enough that I didn't consider it here.)
This has all
On Thu, 13 Apr 2023 at 03:00, Alexandr Nikulin
wrote:
> explain analyze select * from ids join test_part on ids.id=test_part.id where
> ascii(ids.name)=ascii('best case');
> explain analyze select * from ids join test_part on ids.id=test_part.id where
> ascii(ids.name)=ascii('worst case');
>
> T
On 08/03/2023 00:05, Daniel Gustafsson wrote:
When skimming through pg_rewind during a small review I noticed the use of
pipe_read_line for reading arbitrary data from a pipe, the mechanics of which
seemed odd.
Commit 5b2f4afffe6 refactored find_other_exec() and broke out pipe_read_line()
as a s
On 7/4/23 13:23, Alvaro Herrera wrote:
> On 2023-Jul-03, Soumyadeep Chakraborty wrote:
>
>> My colleague, Ashwin, pointed out to me that brininsert's per-tuple init
>> of the revmap access struct can have non-trivial overhead.
>>
>> Turns out he is right. We are saving 24 bytes of memory per-ca
On Tue, Jul 4, 2023 at 5:45 PM Japin Li wrote:
>
> On Tue, 04 Jul 2023 at 17:00, jian he wrote:
> > the following will also crash. no idea why.
> > begin;
> > select count(*) from onek;
> > select relpages from pg_class where relname = 'onek'; --queryA
> >
> > SELECT count(*) FROM pg
Hello,
On Tue, Jul 4, 2023 at 9:36 AM David Rowley wrote:
> I've now pushed the patch.
Thanks for the commit!
--
Best regards,
Yuya Watari
On 2023-Jul-03, Soumyadeep Chakraborty wrote:
> My colleague, Ashwin, pointed out to me that brininsert's per-tuple init
> of the revmap access struct can have non-trivial overhead.
>
> Turns out he is right. We are saving 24 bytes of memory per-call for
> the access struct, and a bit on buffer/l
On Tue, 4 Jul 2023 at 20:12, Richard Guo wrote:
> The v4 patch looks good to me (maybe some cosmetic tweaks are still
> needed for the comments). I think it's now 'Ready for Committer'.
I agree. I went and hit the comments with a large hammer and while
there also adjusted the regression tests. I
Hi,
> This patch hasn't applied in quite some time, and the thread has moved to
> discussing higher lever items rather than the suggested patch, so I'm closing
> this as Returned with Feedback. Please feel free to resubmit when there is
> renewed interest and a concensus on how/what to proceed wi
On Mon, Jul 3, 2023 at 7:45 AM Masahiko Sawada wrote:
>
> Commit 89e46da5e5 allowed us to use indexes for searching on REPLICA
> IDENTITY FULL tables. The documentation explains:
>
> When replica identity full is specified,
> indexes can be used on the subscriber side for searching the rows. Cand
On Tue, 04 Jul 2023 at 17:00, jian he wrote:
> the following will also crash. no idea why.
> begin;
> select count(*) from onek;
> select relpages from pg_class where relname = 'onek'; --queryA
>
> SELECT count(*) FROM pg_buffercache WHERE relfilenode =
> pg_relation_filenode('onek':
the following will also crash. no idea why.
begin;
select count(*) from onek;
select relpages from pg_class where relname = 'onek'; --queryA
SELECT count(*) FROM pg_buffercache WHERE relfilenode =
pg_relation_filenode('onek'::regclass); --queryB
insert into onek values(default);
Have you had a chance to address the comments raised by Michael in his last
review such that a new patch revision can be submitted?
--
Daniel Gustafsson
On Mon, 03 Jul 2023 at 16:26, Palak Chaturvedi
wrote:
> Hi Thomas,
> Thank you for your suggestions. I have added the sql in the meson
> build as well.
>
> On Sat, 1 Jul 2023 at 03:39, Thomas Munro wrote:
>>
>> On Fri, Jun 30, 2023 at 10:47 PM Palak Chaturvedi
>> wrote:
>> > pgbench=# select
On Sun, Jul 2, 2023 at 12:02 PM Miroslav Bendik
wrote:
> Thanks, for suggestions.
>
> On Sun 02. 07. 2023 at 10:18 Richard Guo wrote:
> > 1. For comment "On success, the result list is ordered by pathkeys.", I
> > think it'd be more accurate if we say something like "On success, the
> > result l
Updated patch with more tests and a first attempt at doc updates.
As the commit message and doc now point out, using
WaitForLockersMultiple() makes for a behavior difference with actually
locking multiple tables, in that the combined set of conflicting locks
is obtained only once for all tables, r
> On 17 Mar 2023, at 10:16, Amit Kapila wrote:
> Few minor comments:
Have you had a chance to address the comments raised by Amit in this thread?
--
Daniel Gustafsson
> On 20 Mar 2023, at 16:48, Frédéric Yhuel wrote:
> On 3/20/23 15:58, Gregory Stark (as CFM) wrote:
>> Should we move it to next release at this
>> point? Even if you get time to work on it this commitfest do you think
>> it's likely to be committable in the next few weeks?
>
> It is very unlike
This patch hasn't applied in quite some time, and the thread has moved to
discussing higher lever items rather than the suggested patch, so I'm closing
this as Returned with Feedback. Please feel free to resubmit when there is
renewed interest and a concensus on how/what to proceed with.
--
Danie
On Thu, May 11, 2023 at 01:19:54PM +0900, Michael Paquier wrote:
> On Thu, May 11, 2023 at 12:17:25PM +1200, Thomas Munro wrote:
>> Azure does have an image "Microsoft Windows 11 Preview arm64" to run
>> on Ampere CPUs, which says it's a pre-release version intended for
>> validation, which sounds
Hi,
On 7/3/23 9:11 AM, Michael Paquier wrote:
On Mon, Jul 03, 2023 at 03:57:42PM +0900, Michael Paquier wrote:
Thanks for looking at it and having fixed the issues that were present in
v10.
I think that we should add some options to the perl script to be more
selective with the files generat
On Fri, Dec 30, 2022 at 11:00 AM Richard Guo wrote:
> On Fri, Dec 9, 2022 at 5:16 PM Richard Guo wrote:
>
>> Actually we do have checked PHVs for lateral references, earlier in
>> create_lateral_join_info. But that time we only marked lateral_relids
>> and direct_lateral_relids, without remembe
> On 4 Apr 2023, at 05:36, Nathan Bossart wrote:
>
> I sent this one to the next commitfest and marked it as waiting-on-author
> and targeted for v17. I'm aiming to have something that addresses the
> latest feedback ready for the July commitfest.
Have you had a chance to look at this such that
> On 21 Mar 2023, at 14:44, Mark Wong wrote:
>
> On Mon, Mar 20, 2023 at 01:37:57PM -0400, Gregory Stark (as CFM) wrote:
>> On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote:
>> fficient way to communicate useful information.
>>>
>>> Yeah, I will try to cover all the data types we ship. :) I'll ke
This patch has been waiting on the author for about a year now, so I will close
it as Returned with Feedback. Plesae feel free to resubmit to a future CF when
there is renewed interest in working on this.
--
Daniel Gustafsson
On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote:
> Sure, feel free. I was planning to look at and play more with it.
Well, done.
--
Michael
signature.asc
Description: PGP signature
82 matches
Mail list logo
