On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
> napsal:
>>
>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>> wrote:
>> > On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
>> > wrote:
>> > > On Wed, Mar 6, 2019 at 12:40 AM N
So some PostGIS people were griping (on irc) about how the lack of
CREATE OR REPLACE AGGREGATE made their life difficult for updates. It
struck me that aggregates have acquired a relatively large number of new
attributes in recent years, almost all of which are applicable at
execution time rather t
On Sat, Mar 16, 2019 at 9:12 PM Tom Lane wrote:
> I wrote:
> > Good point. I also see jsonpath_gram.h left behind after maintainer-clean:
>
> Oh, and of potentially more significance: after maintainer-clean and
> re-configure, make fails with
>
> In file included from jsonpath_gram.y:24:
> ../../
Something like "%s: database folder is incompatible" for the first
line sounds kind of better per the feedback gathered. And then on the
second line:
"The database cluster was initialized with block size %u, but
pg_checksums was compiled with block size %u."
Ok. "%s" progname instead of "pg_
On Sun, Mar 17, 2019 at 09:17:02AM +0100, Fabien COELHO wrote:
> I'm not sure that prefixing the two lines with the comment line is very
> elegant, I'd suggest to put spaces, and would still try to shorten the
> second sentence, maybe:
I suggest to keep two lines, and only prefix the first one.
--
Bonjour Michaël-san,
Yes, that would be nice, for now I have focused. For pg_resetwal yes
we could do it easily. Would you like to send a patch?
Here is a proposal for "pg_resetwal".
The implementation basically removes a lot of copy paste and calls the
new update_controlfile function ins
On Sat, Mar 16, 2019 at 11:18:17AM +0100, Magnus Hagander wrote:
> BLCKSZ is very much an internal term. The exposed name through pg_settings
> is block_size, so I think the original was better. Combining that one with
> yours into "initialized with block size %d" etc, makes it a lot nicer.
Yes,
I'm not sure that prefixing the two lines with the comment line is very
elegant, I'd suggest to put spaces, and would still try to shorten the
second sentence, maybe:
I suggest to keep two lines, and only prefix the first one.
As you feel. For me the shorter the better, though, if the infor
On Sun, Mar 17, 2019 at 07:35:16AM +, Andrew Gierth wrote:
> I took a bash at actually writing it and didn't see any obvious problems
> (I'll post the patch in a bit). Is there some reason (other than
> shortage of round tuits) why this might not be a good idea, or why it
> hasn't been done bef
On Sun, Mar 17, 2019 at 10:01:20AM +0100, Fabien COELHO wrote:
> The implementation basically removes a lot of copy paste and calls the new
> update_controlfile function instead. I like removing useless code:-)
Yes, I spent something like 10 minutes looking at that code yesterday
and I agree that
On Sat, Mar 16, 2019 at 10:47 PM Mark G wrote:
> While looking over the new jsonpath stuff I noticed the keyword table
> wasn't declared const. Shouldn't the table and the actual keyword
> strings both be declared const? Perhaps something like the attached
> (untested) patch.
Looks good to me. P
ely after
> > bms_is_member() in the source, to match the header.
>
> I think I've already done the renames in the last patch I submitted (are
> you looking at an older version of the code, perhaps?). I've moved it
> right after bms_is_member - good idea.
>
Ah OK, I was
On Sat, 16 Mar 2019, Euler Taveira wrote:
I think the former one looks like pretty, but which one is preffered?
I don't have a style preference but decided to change to your
suggestion. New version attached.
Again, the patch compiles and works as expected.
--
José Arthur Benetasso Villa
On Sun, Mar 17, 2019 at 10:10 AM Michael Paquier
wrote:
> On Sat, Mar 16, 2019 at 11:18:17AM +0100, Magnus Hagander wrote:
> > BLCKSZ is very much an internal term. The exposed name through
> pg_settings
> > is block_size, so I think the original was better. Combining that one
> with
> > yours in
On Sun, Mar 17, 2019 at 6:47 AM Michael Paquier wrote:
> On Sat, Mar 16, 2019 at 09:18:34AM +0100, Fabien COELHO wrote:
> > I think it would be better to adapt the checksum computation, but this is
> > indeed non trivial because of the way the BLCKSZ constant is hardwired
> into
> > type declarat
On Thu, 14 Mar 2019 at 06:24, Robert Haas wrote:
>
> On Wed, Mar 13, 2019 at 1:09 PM Tom Lane wrote:
> > Sergei Kornilov writes:
> > >> Ugh, I guess so. Or how about changing the message itself to use
> > >> INFO, like we already do in QueuePartitionConstraintValidation?
> >
> > > Fine for me. B
Michaël-san,
The issue here is that trying to embed directly the fsync routines
from file_utils.c into pg_resetwal.c messes up the inclusions because
pg_resetwal.c includes backend-side includes, which themselves touch
fd.h :(
In short your approach avoids some extra mess with the include
depe
On Sat, 16 Mar 2019 at 23:44, Tomas Vondra wrote:
>
> > 28). I just spotted the 1MB limit on the serialised MCV list size. I
> > think this is going to be too limiting. For example, if the stats
> > target is at its maximum of 1, that only leaves around 100 bytes
> > for each item's values, wh
On Sat, 16 Mar 2019 at 23:44, Tomas Vondra wrote:
> >
> > 16). This regression test fails for me:
> >
> > @@ -654,11 +654,11 @@
> > -- check change of unrelated column type does not reset the MCV statistics
> > ALTER TABLE mcv_lists ALTER COLUMN d TYPE VARCHAR(64);
> > SELECT * FROM check_estim
On Sun, Mar 17, 2019 at 12:44:39PM +0100, Fabien COELHO wrote:
> I could remove the two "catalog/" includes from pg_resetwal, I assume that
> you meant these ones.
Not exactly. What I meant is that if you try to call directly
fsync_fname and fsync_parent_path from file_utils.h, then you get into
Hello
> If we don't have this for SET NOT NULL then we should either add it or
> remove the one from ATTACH PARTITION.
I proposed to lower report level to debug1 in a separate thread:
https://www.postgresql.org/message-id/4859321552643736%40myt5-02b80404fd9e.qloud-c.yandex.net
Possible better wo
Hi;
Attached is my second attempt at the pg_rewind change which allows one to
include only a minimal set. To my understanding, all past feedback has
been addressed.
The current patch does not change default behavior at present. It does add
a --data-only flag which allows pg_rewind to only rewin
Hi,
On 3/17/19 12:47 PM, Dean Rasheed wrote:
> On Sat, 16 Mar 2019 at 23:44, Tomas Vondra
> wrote:
>>
>>> 28). I just spotted the 1MB limit on the serialised MCV list size. I
>>> think this is going to be too limiting. For example, if the stats
>>> target is at its maximum of 1, that only le
On 3/17/19 1:14 PM, Dean Rasheed wrote:
> On Sat, 16 Mar 2019 at 23:44, Tomas Vondra
> wrote:
>>>
>>> 16). This regression test fails for me:
>>>
>>> @@ -654,11 +654,11 @@
>>> -- check change of unrelated column type does not reset the MCV statistics
>>> ALTER TABLE mcv_lists ALTER COLUMN d
On 3/17/19 4:03 AM, Alexander Korotkov wrote:
> On Sat, Mar 16, 2019 at 9:12 PM Tom Lane wrote:
>> I wrote:
>>> Good point. I also see jsonpath_gram.h left behind after maintainer-clean:
>> Oh, and of potentially more significance: after maintainer-clean and
>> re-configure, make fails with
>>
Michael Paquier writes:
> On Sun, Mar 17, 2019 at 07:35:16AM +, Andrew Gierth wrote:
>> I took a bash at actually writing it and didn't see any obvious problems
>> (I'll post the patch in a bit). Is there some reason (other than
>> shortage of round tuits) why this might not be a good idea, or
Many of us have faced character encoding issues because we are not in control
of our input sources and made the common assumption that UTF-8 covers
everything.
In my lab, as an example, some of our social media posts have included ZawGyi
Burmese character sets rather than Unicode Burmese. (Bec
Andrew Dunstan writes:
> Why are we installing the jsonpath_gram.h file? It's not going to be
> used by anything else, is it? TBH, I'm not sure I see why we're
> installing the scanner.h file either.
As near as I can see, jsonpath_gram.h and jsonpath_scanner.h exist only
for communication between
Chapman Flack writes:
> On 03/16/19 17:21, Tom Lane wrote:
>> Hm, so, maybe just
>>
>> (1) always try to parse as document. If successful, we're done.
>>
>> (2) otherwise, if allowed by xmloption, try to parse using our
>> current logic for the CONTENT case.
> What I don't like about that is t
On Sun, Mar 17, 2019 at 6:03 PM Tom Lane wrote:
> Andrew Dunstan writes:
> > Why are we installing the jsonpath_gram.h file? It's not going to be
> > used by anything else, is it? TBH, I'm not sure I see why we're
> > installing the scanner.h file either.
>
> As near as I can see, jsonpath_gram.h
On 3/17/19 3:13 AM, Alexander Korotkov wrote:
> On Sat, Mar 16, 2019 at 9:39 PM Pavel Stehule wrote:
>> so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov
>> napsal:
>>>
>>> On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov
>>> wrote:
On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
Hi!
On Sun, Mar 17, 2019 at 7:46 PM Jonathan S. Katz wrote:
> Like Pavel, I did some basic testing of the patch (on current HEAD
> 4178d8b91c) trying out various JSON path expressions, and yes, it all
> worked. I had a brief scare while testing on 4178d8b91c where initdb was
> failing on the boot
On 3/17/19 12:55 PM, Alexander Korotkov wrote:
>
>> However, when I did something a little more complex, like the below:
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.length ? (@ < 150)';
>>
>> SELECT count(*)
>> FROM news_feed
>> WHERE data @? '$.content ? (@ like_regex "^Start")';
On Sun, Mar 17, 2019 at 8:00 PM Jonathan S. Katz wrote:
> On 3/17/19 12:55 PM, Alexander Korotkov wrote:
> >
> >> However, when I did something a little more complex, like the below:
> >>
> >> SELECT count(*)
> >> FROM news_feed
> >> WHERE data @? '$.length ? (@ < 150)';
> >>
> >> SELECT count(*)
On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>
> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
I just used "USING gin(col)" so jsonb_ops.
Thanks,
Jonathan
signature.asc
Description: OpenPGP digital signature
On 03/17/19 11:45, Tom Lane wrote:
> Chapman Flack writes:
>> On 03/16/19 17:21, Tom Lane wrote:
>>> (1) always try to parse as document. If successful, we're done.
>>> (2) otherwise, if allowed by xmloption, try to parse using our
>
>> What I don't like about that is that (a) the input could be
On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
> >
> > Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>
> I just used "USING gin(col)" so jsonb_ops.
I see. So, jsonb_ops extracts from this query only existence of
.lengt
Chapman Flack writes:
> What I was doing in the patch is the reverse: parsing with the expectation
> of CONTENT to see if a DTD gets tripped over. It isn't allowed for an
> element to precede a DTD, so that approach can be expected to fail fast
> if the other branch needs to be taken.
Ah, right.
You have one error at the end of update_controlfile(), where close()
could issue a frontend-like error for the backend, calling exit() on the
way. That's not good. (No need to send a new patch, I'll fix it
myself.)
Indeed. I meant to merge the "if (close(fd))", but ended merging the error
On 03/17/19 13:16, Tom Lane wrote:
> Chapman Flack writes:
>> What I was doing in the patch is the reverse: parsing with the expectation
>> of CONTENT to see if a DTD gets tripped over. It isn't allowed for an
>> element to precede a DTD, so that approach can be expected to fail fast
>> if the oth
On 3/17/19 1:14 PM, Alexander Korotkov wrote:
> On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
>> On 3/17/19 1:02 PM, Alexander Korotkov wrote:
>>>
>>> Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
>>
>> I just used "USING gin(col)" so jsonb_ops.
>
> I see. So, json
Chapman Flack writes:
> On 03/17/19 13:16, Tom Lane wrote:
>> Do we need a pre-scan at all?
> Without it, we double the time to a failure result in every case that
> should actually fail, as well as in this one corner case that we want to
> see succeed, and the question you posed earlier about wh
I wrote:
> The cause of this error is that RequestCheckpoint will give up and fail
> after just 2 seconds, which evidently is not long enough on slow or
> heavily loaded machines. Since there isn't any good reason why the
> checkpointer wouldn't be running, I'm inclined to swing a large hammer
> a
> "Tom" == Tom Lane writes:
Tom> Yeah, it seems like mostly a lack-of-round-tuits problem.
Tom> Updating the aggregate's dependencies correctly might be a bit
Tom> tricky, but it can't be any worse than the corresponding problem
Tom> for functions...
I was worried about that myself but
David Rowley writes:
> [ eclass_indexes_v3.patch ]
I looked at this for a little bit. I'm on board with the basic idea
of assigning integer indexes to the ECs and keeping bitmapsets of
relevant EC indexes in RelOptInfos. However ... man, is that
delete_eclass() thing ugly. And slow, and fragil
On 03/17/19 15:06, Tom Lane wrote:
> The error message issue is indeed a concern, but I don't see why it's
> complicated if you agree that
>
>> If the query asked for CONTENT, any error result should be one you could get
>> when parsing as CONTENT.
>
> That just requires us to save the first erro
On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro wrote:
> On Wed, Mar 6, 2019 at 9:21 AM Tom Lane wrote:
> > Yeah, I've still been unable to reproduce even with the sleep idea,
> > so eelpout is definitely looking like a special snowflake from here.
> > In any case, there seems little doubt that gett
Thomas Munro writes:
> On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro wrote:
>> I opened a bug report with OpenSSL, let's see what they say:
>> https://github.com/openssl/openssl/issues/8500
> This was an intentional change in TLS1.3, reducing round trips by
> verifying the client certificate late
On 17.03.2019 21:29, Jonathan S. Katz wrote:
On 3/17/19 1:14 PM, Alexander Korotkov wrote:
On Sun, Mar 17, 2019 at 8:06 PM Jonathan S. Katz wrote:
On 3/17/19 1:02 PM, Alexander Korotkov wrote:
Thank you for the explanation. Is it jsonb_ops or jsonb_path_ops?
I just used "USING gin(col)" so
I wrote:
> Thomas Munro writes:
>> This was an intentional change in TLS1.3, reducing round trips by
>> verifying the client certificate later.
> Ugh. So probably we can reproduce it elsewhere if we use cutting-edge
> OpenSSL versions.
I installed OpenSSL 1.1.1a on my Mac laptop. I got through
On Tue, Oct 02, 2018 at 10:53:40AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> >> FWIW, my problem with this patch is that I remain unconvinced of the basic
> >> correctness of the transform (specifically the unique-ification approach
On Sun, Mar 17, 2019 at 12:01:31PM +0100, Magnus Hagander wrote:
> LGTM.
Okay, committed.
--
Michael
signature.asc
Description: PGP signature
On Sat, Mar 16, 2019 at 10:55 PM, Euler Taveira wrote:
> > Is there no need to rewrite the Description in the Doc to state we should
> specify either -d or -f option?
> > (and also it might be better to write if -l option is given, neither
> > -d nor -f option isn't necessarily needed.)
> >
> I don
Hi Ram,
Thanks for doing this; I've been overestimating my ability to get to things
over the last couple of weeks.
I've looked at the patch and have made one minor change. I had moved all
the imports up to the top, to keep them in one place (and I think some had
originally been used only by the Py
On Fri, Mar 15, 2019 at 6:20 AM, Imai, Yoshikazu wrote:
> Upon committing this, we have to care this patch break backwards
> compatibility, but I haven't seen any complaints so far. If there are
> no objections, I will set this patch to ready for committer.
Jose had set this to ready for committer
Hi,
Given a Portal, or an _SPI_plan, is there a practical way to tell whether
it came from a query with FOR UPDATE or FOR SHARE?
Regards,
-Chap
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> Based on your comment it seems to me that 'socket_timeout' should be
> connected with statement_timeout. I mean that end-user should wait
> statement_timeout + 'socket_timeout' for returning control. It looks much
> more safer for m
Thanks for looking at this.
On Mon, 18 Mar 2019 at 10:08, Tom Lane wrote:
> I looked at this for a little bit. I'm on board with the basic idea
> of assigning integer indexes to the ECs and keeping bitmapsets of
> relevant EC indexes in RelOptInfos. However ... man, is that
> delete_eclass() th
On Saturday, March 16, 2019 5:40 PM (GMT+9), Fabien COELHO wrote:
> > Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch
> > and continue discussion about 'socket_timeout'?
> I can apply nothing, I'm just a small-time reviewer.
> Committers on the thread are Michaël-san and Ro
On Thu, Mar 14, 2019 at 09:04:41AM +0900, Michael Paquier wrote:
> Thanks for confirming, Mythun. I'll think about the logic of this
> patch for a couple of days in the background, then I'll try to commit
> it likely at the beginning of next week.
Committed. I have spent extra time polishing the
On 2019/03/15 1:02, Robert Haas wrote:
> On Thu, Mar 14, 2019 at 3:13 AM Amit Langote
> wrote:
>> I'm curious why DestroyPartitionDirectory doesn't do
>> hash_destroy(pdir->pdir_hash)?
>
> What would be the point? It's more efficient to let context teardown
> take care of it.
Yeah, I only notic
On 2019/03/15 2:56, Robert Haas wrote:
> On Thu, Mar 14, 2019 at 1:16 PM Tom Lane wrote:
>> Actually, now that I've absorbed a bit more about 898e5e329,
>> I don't like very much about it at all. I think having it
>> try to hang onto pointers into the relcache is a completely
>> wrongheaded desig
On Fri, Mar 15, 2019 at 3:25 PM Amit Kapila wrote:
>
> I have committed the latest version of this patch. I think we can
> wait for a day or two see if there is any complain from buildfarm or
> in general and then we can close this CF entry.
>
Closed this CF entry.
--
With Regards,
Amit Kapila
On Tue, Feb 26, 2019 at 7:20 PM Masahiko Sawada wrote:
>
> On Tue, Feb 26, 2019 at 1:35 PM Haribabu Kommi
> wrote:
> >
> > On Thu, Feb 14, 2019 at 9:17 PM Masahiko Sawada
> > wrote:
> >>
> >> Thank you. Attached the rebased patch.
> >
> >
> > I ran some performance tests to compare the paralle
Hi Nikolay,
This patch does not apply. Please refer to http://commitfest.cputube.org/ and
update it.
How about separating your patch by feature or units that can be phased commit.
For example, adding assert macro at first, refactoring StdRdOptions by the
next, etc.
So I change status to "Waiti
On Sun, Mar 17, 2019 at 5:53 PM Arseny Sher wrote:
> Thomas Munro writes:
>
> > 1. Why does pmdie()'s SIGTERM case terminate parallel workers
> > immediately? That breaks aborts running parallel queries, so they
> > don't get to end their work normally.
> > 2. Why are new parallel workers not
On Sun, Mar 17, 2019 at 12:44:39PM +0100, Fabien COELHO wrote:
> I kept the initial no-parameter function which calls the new one with 4
> parameters, though, because it looks more homogeneous this way in the
> backend code. This is debatable.
From a compatibility point of view, your position actu
On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> I also added test cases and some docs. I don't know if the docs are
> sufficient. Feedback is appreciated.
To be honest, I don't think that this approach is a good idea per the
same reasons as mentioned the last time, as this can c
On Mon, 18 Mar 2019 at 14:06, David Rowley wrote:
>
> On Mon, 18 Mar 2019 at 10:08, Tom Lane wrote:
> > If that doesn't work (because we need the index info sooner), maybe we
> > could consider never removing ECs from eq_classes, so that their indices
> > never change, then teaching most/all of t
Chapman Flack writes:
> Given a Portal, or an _SPI_plan, is there a practical way to tell whether
> it came from a query with FOR UPDATE or FOR SHARE?
In principle, you could do something like drilling down into the plan
tree to see if there's a LockRows node, but this wouldn't necessarily
be a g
Hello.
At Sun, 17 Mar 2019 20:23:05 -0400, Hugh Ranalli wrote in
> Hi Ram,
> Thanks for doing this; I've been overestimating my ability to get to things
> over the last couple of weeks.
>
> I've looked at the patch and have made one minor change. I had moved all
> the imports up to the top, to
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 3/2/19 12:03 AM, Robert Haas wrote:
> > On Tue, Sep 18, 2018 at 10:37 AM Michael Banck
> > wrote:
> >> I have added a retry for this as well now, without a pg_sleep() as well.
> >> This catches around 80% of the half-reads, but
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> If we want to run it from the server itself, then I guess a background
> worker would be a better solution. Incidentally, that's something I've
> been toying with some time ago, see [1].
So, I'm a big fan of this idea of having a b
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-03-12 14:42:14 +0900, Michael Paquier wrote:
> > On Mon, Mar 11, 2019 at 08:38:56PM +, Regina Obe wrote:
> > > I tested on windows mingw64 (as of a week ago) and confirmed the
> > > patch applies cleanly and significantly faster
On Mon, Mar 18, 2019 at 01:43:08AM -0400, Stephen Frost wrote:
> To be clear, I agree completely that we don't want to be reporting false
> positives or "this might mean corruption!" to users running the tool,
> but I haven't seen a good explaination of why this needs to involve the
> server to avo
Bonjour Michaël,
Here are my notes about the fixes:
Thanks for the fixes.
- pg_resetwal got broken because the path to the control file was
incorrect. Running tests of pg_upgrade or the TAP tests of
pg_resetwal showed the failure.
Hmmm… I thought I had done that with "make check-world":-
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 14, 2019 at 7:34 PM Peter Eisentraut
> wrote:
> > I think the potential problems of getting this wrong are bigger than the
> > issue we are trying to fix.
>
> I think the question is: how do we know what the user intended? If
Greetings,
* Auguste Comte (minasi...@gmail.com) wrote:
> Hello Moodle Team,
This isn't the Moodle team, I'm guessing you sent this to the wrong
place or at least forgot to update your email.
> I am a student who is currently take computer science classes at Glendale
> Community College, AZ wh
Hello.
At Mon, 18 Mar 2019 14:13:34 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190318.141334.186469242.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> At Sun, 17 Mar 2019 20:23:05 -0400, Hugh Ranalli wrote in
>
> > Hi Ram,
> > Thanks for doing this; I've been overestimating my
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> > I also added test cases and some docs. I don't know if the docs are
> > sufficient. Feedback is appreciated.
>
> To be honest, I don't think that this approach is a goo
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Mar 18, 2019 at 01:43:08AM -0400, Stephen Frost wrote:
> > To be clear, I agree completely that we don't want to be reporting false
> > positives or "this might mean corruption!" to users running the tool,
> > but I haven't seen a
81 matches
Mail list logo
