On Wed, Feb 19, 2020 at 03:00:54PM +0900, Kyotaro Horiguchi wrote:
> I have had support requests related to broken block several times, and
> (I think) most of *them* had hard time to locate the broken block or
> even broken file. I don't think it is useles at all, but I'm not sure
> it is worth
I think attached v35nm is ready for commit to master. Would anyone like to
talk me out of back-patching this? I would not enjoy back-patching it, but
it's hard to justify lack of back-patch for a data-loss bug.
Notable changes since v34:
- Separate a few freestanding fixes into their own
вт, 18 февр. 2020 г. в 06:23, Thomas Munro :
> On Mon, Feb 10, 2020 at 8:20 PM Craig Ringer wrote:
> > On Wed, 5 Feb 2020 at 21:36, Kirill Bychik wrote:
> > > Patch is separated in two parts: core changes and pg_stat_statements
> > > additions. Essentially the extension has its schema updated to
On Wed, Feb 19, 2020 at 3:56 PM Amit Langote wrote:
> On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule wrote:
> > st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
> > napsal:
> >> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
> >> napsal:
> >>> > I updated the patch to do that.
> >>> >
> >>> >
On Mon, Dec 30, 2019 at 7:43 PM Andrey Borodin wrote:
> PFA rebased patch.
Hi Andrey,
This looks really interesting, and I am sure there are a lot of GIS
people who would love to see dramatically faster and smaller indexes
in PG13. I don't know enough to comment on the details, but here are
On Wed, Feb 19, 2020 at 3:38 PM Pavel Stehule wrote:
> st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
> napsal:
>> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
>> napsal:
>>> > I updated the patch to do that.
>>> >
>>> > With the new patch, `select foo()`, with inline-able sql_incr() in it,
st 19. 2. 2020 v 7:30 odesílatel Pavel Stehule
napsal:
>
>
> út 18. 2. 2020 v 17:08 odesílatel Amit Langote
> napsal:
>
>> On Tue, Feb 18, 2020 at 6:56 PM Amit Langote
>> wrote:
>> > On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule
>> wrote:
>> > > út 18. 2. 2020 v 6:03 odesílatel Amit Langote <
út 18. 2. 2020 v 17:08 odesílatel Amit Langote
napsal:
> On Tue, Feb 18, 2020 at 6:56 PM Amit Langote
> wrote:
> > On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule
> wrote:
> > > út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> napsal:
> > >> I didn't send the patch, because it didn't handle the
At Wed, 19 Feb 2020 13:28:04 +0900, Michael Paquier wrote
in
> On Wed, Feb 19, 2020 at 01:07:36PM +0900, Kyotaro Horiguchi wrote:
> > If we also verify checksum in md layer, callback is overkill since the
> > immediate caller consumes the event immediately. We can signal the
> > error by
On Mon, Feb 17, 2020 at 2:42 AM Tom Lane wrote:
>
> Andres Freund writes:
> > On 2020-02-14 13:34:03 -0500, Robert Haas wrote:
> >> I think the group locking + deadlock detection things are more
> >> fundamental than you might be crediting, but I agree that having
> >> parallel mechanisms has
Hello.
I saw a failure of vcregress check with the following message several
times, on a machine under a heavy load and maybe with realtime virus
scanning.
> pg_regress: could not create directory ".../testtablespace": Permission
> denied.
I found that pg_regress repeats the sequence
After thinking about this awhile longer, I'm starting to believe
we should do some of each. That is, the stub replacement for
plpython2.so should redirect "plpythonu" functions to plpython3.so,
but throw errors for "plpython2u" functions. This is not because
of any technical difference between
On Wed, Feb 19, 2020 at 01:07:36PM +0900, Kyotaro Horiguchi wrote:
> If we also verify checksum in md layer, callback is overkill since the
> immediate caller consumes the event immediately. We can signal the
> error by somehow returning a file tag.
FWIW, I am wondering if there is any need for
On Tue, Feb 18, 2020 at 7:51 PM Mike Blackwell
wrote:
> On Sun, Feb 16, 2020 at 12:51 AM Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> wrote:
>
>>
>> IIRC, in_quote only matters here in CSV mode (because CSV fields can
>> have embedded newlines). So why not just forbid parallel copy in CSV
On Tue, Feb 18, 2020 at 8:08 PM Ants Aasma wrote:
>
> On Tue, 18 Feb 2020 at 15:21, Amit Kapila wrote:
> >
> > On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma wrote:
> > >
> > > On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> > > > This is something similar to what I had also in mind for this
On Tue, Feb 18, 2020 at 05:54:43PM +0900, Kyotaro Horiguchi wrote:
> I understand that this is not for back-patching.
Cleanups don't go to back-branches.
> At Tue, 18 Feb 2020 16:44:59 +0900, Michael Paquier
> wrote in
> The unmodified section just above is griping that "Strange they call
>
On Tue, Feb 18, 2020 at 8:41 PM David Fetter wrote:
>
> On Tue, Feb 18, 2020 at 06:51:29PM +0530, Amit Kapila wrote:
> > On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma wrote:
> > >
> > > On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> > > > This is something similar to what I had also in mind
Hello. Thank you for the new patch.
At Tue, 18 Feb 2020 09:27:39 +0800, Hubert Zhang wrote in
> On Wed, Feb 12, 2020 at 5:22 PM Hubert Zhang wrote:
>
> > Thanks Andres,
> >
> > On Tue, Feb 11, 2020 at 5:30 AM Andres Freund wrote:
> >
> >> HHi,
> >>
> >> On 2020-02-10 16:04:21 +0800, Hubert
On Tue, Feb 18, 2020 at 12:26:06PM +0100, Juan José Santamaría Flecha wrote:
> I cannot point when SetEnv.bat was exactly dropped, probably Windows 7 SDK
> was the place where it was included [1], so that needs to be updated.
>
> Using VS2019 and VS2017 this would be done using VsDevCmd.bat [2],
On Tue, Feb 18, 2020 at 12:05:42PM +0100, Juan José Santamaría Flecha wrote:
> Maybe this needs a specific thread, as it is not quite cruft but something
> that will require maintenance.
Makes sense. I have discarded that part for now.
--
Michael
signature.asc
Description: PGP signature
On Tue, Feb 18, 2020 at 1:11 PM Amit Langote wrote:
> On Tue, Feb 18, 2020 at 6:56 AM Alvaro Herrera
> wrote:
> @@ -16541,7 +16493,7 @@ CloneRowTriggersToPartition(Relation parent,
> Relation partition)
> *
> * However, if our parent is a partitioned relation, there might be
>
> This is
On Tue, 11 Feb 2020 at 09:58, Andres Freund wrote:
> Isn't that basically a problem of the past by now? Partially due to
> changed laws (e.g. France, which used to be a problematic case), but
> also because it's basically futile to have import restrictions on
> cryptography by now. Just about
On Tue, Feb 18, 2020 at 9:32 PM Fujii Masao wrote:
> OK, I changed the doc that way. Attached the updated version of the patch.
Thank you. Looks good to me.
Regards,
Amit
On Mon, Feb 10, 2020 at 1:05 AM Floris Van Nee wrote:
> I ran all the tests on two different machines, several times for 1 hour each
> time. I'm still having a hard time getting reliable results for the 30
> clients case though. I'm pretty certain the patches bring a performance
> benefit, but
On Wed, 19 Feb 2020 at 09:12, Kohei KaiGai wrote:
> I noticed that variables in PL/Python are not released at the end of
> procedure.
> Does it expected behavior?
PL/Python vars are freed when the interpreter instance is freed and
their refcounts reach zero.
I believe we use one
On Tue, Feb 18, 2020 at 4:45 PM Thomas Munro wrote:
> Yeah, for CF entries with multiple threads, it currently looks at
> whichever thread has the most recent email on it, and then it finds
> the most recent patch set on that thread. Perhaps it should look at
> all the registered threads and
Hello,
I noticed that variables in PL/Python are not released at the end of procedure.
Does it expected behavior?
See this example below:
https://github.com/heterodb/pg-strom/blob/master/test/input/arrow_python.source#L53
This PL/Python function maps a GPU buffer as cupy.ndarray object by
On Wed, Feb 19, 2020 at 1:35 PM Peter Geoghegan wrote:
> On Tue, Feb 18, 2020 at 12:55 PM Thomas Munro wrote:
> > The cfbot seems to be showing "pg_regress: initdb failed" on Ubuntu,
> > with an assertion failure like this:
> >
> > #2 0x008e594f in ExceptionalCondition
> >
On Tue, Feb 18, 2020 at 12:55 PM Thomas Munro wrote:
> The cfbot seems to be showing "pg_regress: initdb failed" on Ubuntu,
> with an assertion failure like this:
>
> #2 0x008e594f in ExceptionalCondition
> (conditionName=conditionName@entry=0x949098 "BTreeTupleGetNAtts(itup,
> rel) >=
After manually applied the patch, a diff regenerated is attached.
On 2020-02-18 4:16 p.m., David Zhang wrote:
1. Tried to apply the patch to PG 12.2 commit
45b88269a353ad93744772791feb6d01bc7e1e42 (HEAD -> REL_12_2, tag: REL_12_2), it
doesn't work. Then tried to check the patch, and found the
Hi
I have tried the attached kms_v3 patch and have some comments:
1) In the comments, I think you meant hmac + iv + encrypted data instead of iv
+ hmac + encrypted data?
---> in kmgr_wrap_key( ):
+ /*
+ * Assemble the wrapped key. The order of the wrapped key is iv, hmac
1. Tried to apply the patch to PG 12.2 commit
45b88269a353ad93744772791feb6d01bc7e1e42 (HEAD -> REL_12_2, tag: REL_12_2), it
doesn't work. Then tried to check the patch, and found the errors showing below.
$ git apply --check
0001-Fastpath-for-sending-changes-to-output-plugin-in-log.patch
On Tue, 18 Feb 2020 22:03:47 +0900
nuko yokohama wrote:
> Hi.
>
> SELECT statements with a TABLESAMPLE clause should be rejected.
>
> Currently, CREATE INCREMENTAL MATERIALIZED VIEW allows SELECT statements
> with the TABLESAMPLE clause.
> However, the result of this SELECT statement is
On Tue, Feb 18, 2020 at 10:57 AM Tomas Vondra
wrote:
> Hi,
>
> I wanted to take a look at this thread and do a review, but it's not
> very clear to me if the recent patches posted here are independent or
> how exactly they fit together. I see
>
> 1) hashagg-20200212-1.patch (2020/02/13 by Jeff)
On Fri, Jan 31, 2020 at 9:52 AM Melanie Plageman
wrote:
> I'm bumping this to the next commitfest because I haven't had a chance
> to address the questions posed by Dmitry. I'm sure I'll get to it in
> the next few weeks.
>
> > I believe it would be beneficial to add this potential API extension
P.S.
Also, should we enable vt100 mode in case of PG_COLOR=always? I think yes.
On Tue, 11 Feb 2020 at 12:42, amul sul wrote:
>
> On Fri, Jan 24, 2020 at 11:31 AM Masahiko Sawada
> wrote:
>>
>> On Fri, 6 Dec 2019 at 17:33, Kyotaro Horiguchi
>> wrote:
>> >
>> > Hello.
>> >
>> > This is the reased (and a bit fixed) version of the patch. This
>> > applies on the master HEAD
Hello everyone.
> Please find attached a version that supports older Mingw versions and SDKs.
I have checked the patch source code and it seems to be working. But a
few moments I want to mention:
I think it is not good idea to mix the logic of detecting the fact of
TTY with enabling of the
On Wed, Feb 19, 2020 at 7:10 AM Andrew Dunstan
wrote:
>
> On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
> >
> > On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> > wrote:
> > > Not sure if the placement is what you want, but maybe something like this?
> >
> > Hi Andrew, FYI this failed
On Tue, Feb 18, 2020 at 2:16 AM Alexander Korotkov
wrote:
> Great, thank you very much!
No problem!
My remarks here are based on
"amcheck-btree-improve-missing-parent-downlinks-check-6.patch". I have
found a false positive corruption report bug in this latest version --
see note below about
On Mon, Feb 10, 2020 at 10:05 PM Floris Van Nee
wrote:
> > The interesting thing now is the role of the "negative infinity test"
> > patch (the 0003-* patch) in all of this. I suspect that it may not be
> > helping us
> > much here. I wonder, could you test the following configurations to settle
On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
>
> On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> wrote:
> > Not sure if the placement is what you want, but maybe something like this?
>
> Hi Andrew, FYI this failed here:
>
> t/001_testfunc.pl .. Bailout called. Further testing stopped:
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
The issue has been verified using below steps:
1. $ initdb -D
>
> So, as with Jesse's example, what I'm wondering is whether or not 2to3
> will fix that for you (or even flag it). The basic difference between
> the two alternatives I suggested is whether we force people to put their
> python function through that converter before we'll even try to run it.
>
Hi,
I wanted to take a look at this thread and do a review, but it's not
very clear to me if the recent patches posted here are independent or
how exactly they fit together. I see
1) hashagg-20200212-1.patch (2020/02/13 by Jeff)
2) refactor.patch (2020/02/13 by Jeff)
3)
On Tue, Feb 18, 2020 at 12:10 PM Nagaraj Raj wrote:
>
> Below are the same configurations ins .conf file before and after updagrade
>
> show max_connections; = 1743
> show shared_buffers = "4057840kB"
> show effective_cache_size = "8115688kB"
> show maintenance_work_mem = "259MB"
> show
hi,
I did some further research on this bug. Here is the summary:
1. Tried to wrap "fputs" similar to "fprintf" redefined by "pg_fprintf",
but it ended up with too much error due to "fputs" is called everywhere
in "print_unaligned_text". If add an extra static variable to track the
output
Below are the same configurations ins .conf file before and after updagrade
show max_connections; = 1743show shared_buffers = "4057840kB"show
effective_cache_size = "8115688kB"show maintenance_work_mem = "259MB"show
checkpoint_completion_target = "0.9"show wal_buffers = "16MB"show
On Tue, Feb 18, 2020 at 05:46:28PM +, Nagaraj Raj wrote:
after upgrade Postgres to v9.6.11 from v9.6.9 DB running out of memory issues
no world load has changed before and after upgrade.
spec: RAM 16gb,4vCore
Any bug reported like this or suggestions on how to fix this issue? I
On Tue, Feb 18, 2020 at 6:56 PM Amit Langote wrote:
> On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule wrote:
> > út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> > napsal:
> >> I didn't send the patch, because it didn't handle the cases where a
> >> simple expression consists of an inline-able
Corey Huinker writes:
>> A possible gotcha in this approach is if there are any python 2/3
>> incompatibilities that would not manifest as syntax errors or
>> obvious runtime errors, but would allow old code to execute and
>> silently do the wrong thing.
> Unfortunately, I think there are cases
On Tue, Feb 18, 2020 at 12:26 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> [Edit] ... probably Windows 7 SDK was the *last* place where it was
included [1]...
>
> Regards,
>
> Juan José Santamaría Flecha
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > On 2020-01-29 14:41:16 -0500, Tom Lane wrote:
> >> pgcrypto
>
> > FWIW, given the code quality, I'm doubtful about putting itq into the
> > trusted
> > section.
>
> I don't particularly have an opinion about that
On Tue, Feb 18, 2020 at 06:51:29PM +0530, Amit Kapila wrote:
> On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma wrote:
> >
> > On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> > > This is something similar to what I had also in mind for this idea. I
> > > had thought of handing over complete chunk
On Tue, 18 Feb 2020 at 15:21, Amit Kapila wrote:
>
> On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma wrote:
> >
> > On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> > > This is something similar to what I had also in mind for this idea. I
> > > had thought of handing over complete chunk (64K or
Greg Stark writes:
> For the user visible ctid we could just arbitrarily declare that the ctid
> returned by an IOS is the head of the HOT update chain instead of the tail.
No, I don't think that'd work at all, because that tuple might be dead.
A minimum expectation is that "SELECT ... WHERE
On Sun, Feb 16, 2020 at 12:51 AM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> IIRC, in_quote only matters here in CSV mode (because CSV fields can
> have embedded newlines). So why not just forbid parallel copy in CSV
> mode, at least for now? I guess it depends on the actual use
On Mon, Feb 17, 2020 at 5:58 AM Thomas Munro wrote:
>
> On Thu, Feb 13, 2020 at 8:13 AM Julien Rouhaud wrote:
> > Hearing no complaints on the suggestions, I'm attaching v8 to address that:
> >
> > - pg_dump is now using a binary_upgrade_set_index_coll_version() function
> > rather than plain
For the user visible ctid we could just arbitrarily declare that the ctid
returned by an IOS is the head of the HOT update chain instead of the tail.
It might be a bit confusing when sequential scans return the tail (or
whichever member is visible). But it's not really wrong, all the members of
On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma wrote:
>
> On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> > This is something similar to what I had also in mind for this idea. I
> > had thought of handing over complete chunk (64K or whatever we
> > decide). The one thing that slightly bothers
Hi.
SELECT statements with a TABLESAMPLE clause should be rejected.
Currently, CREATE INCREMENTAL MATERIALIZED VIEW allows SELECT statements
with the TABLESAMPLE clause.
However, the result of this SELECT statement is undefined and should be
rejected when specified in CREATE INCREMENTAL
On 2020/02/18 16:53, Amit Langote wrote:
On Tue, Feb 18, 2020 at 4:42 PM Fujii Masao wrote:
On 2020/02/18 16:02, Amit Langote wrote:
I noticed that there is missing tag in the documentation changes:
Could you tell me where I should add tag?
+
+ waiting for checkpoint to
On Tue, 18 Feb 2020 at 12:20, Amit Kapila wrote:
> This is something similar to what I had also in mind for this idea. I
> had thought of handing over complete chunk (64K or whatever we
> decide). The one thing that slightly bothers me is that we will add
> some additional overhead of copying
On Tue, Feb 18, 2020 at 9:56 AM Kyotaro Horiguchi
wrote:
>
> https://www.postgresql.org/docs/current/install-windows-full.html
> > In recent SDK versions you can change the targeted CPU architecture,
> > build type, and target OS by using the setenv command, e.g. setenv
> > /x86 /release /xp to
On Tue, Feb 18, 2020 at 7:54 AM Michael Paquier wrote:
> On Thu, Dec 19, 2019 at 08:09:45PM +0100, Juan José Santamaría Flecha
> wrote:
> > This is probably not an issue for the supported MSVC and their SDK, but
> > current MinGW defaults to Windows 2003 [1]. So I would suggest a logic
> like:
>
At Tue, 18 Feb 2020 15:59:36 +0530, Amit Kapila wrote
in
> On Tue, Feb 18, 2020 at 7:28 AM Kyotaro Horiguchi
> wrote:
> >
> > In an extreme case, if we didn't see a QUOTE in a chunk, we cannot
> > know the chunk is in a quoted section or not, until all the past
> > chunks are parsed. After
Oops. I played on a wrong branch and got stuck in slow build on
Windows...
At Tue, 18 Feb 2020 00:53:37 -0800, Noah Misch wrote in
> On Tue, Feb 18, 2020 at 03:56:15PM +1300, Thomas Munro wrote:
> > CREATE TYPE priv_testtype1 AS (a int, b text);
> > +ERROR: relation 24844 deleted while still in
On Tue, Feb 18, 2020 at 7:28 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 17 Feb 2020 16:49:22 +0530, Amit Kapila
> wrote in
> > On Sun, Feb 16, 2020 at 12:21 PM Andrew Dunstan
> > wrote:
> > > On 2/15/20 7:32 AM, Amit Kapila wrote:
> > > > On Sat, Feb 15, 2020 at 4:08 PM Alastair Turner
> > > >
On Mon, Feb 17, 2020 at 8:34 PM Ants Aasma wrote:
>
> On Sat, 15 Feb 2020 at 14:32, Amit Kapila wrote:
> > Good point and I agree with you that having a single process would
> > avoid any such stuff. However, I will think some more on it and if
> > you/anyone else gets some idea on how to deal
On Tue, Feb 18, 2020 at 1:15 PM Alexander Korotkov
wrote:
> On Fri, Jan 24, 2020 at 4:31 AM Peter Geoghegan wrote:
> > On Wed, Jan 22, 2020 at 6:41 PM Alexander Korotkov
> > wrote:
> > > Rebased patch is attached. Sorry for so huge delay.
> >
> > I really like this patch. Your interest in
Hi, Peter!
On Fri, Jan 24, 2020 at 4:31 AM Peter Geoghegan wrote:
> On Wed, Jan 22, 2020 at 6:41 PM Alexander Korotkov
> wrote:
> > Rebased patch is attached. Sorry for so huge delay.
>
> I really like this patch. Your interest in amcheck is something that
> makes me feel good about having put
On Tue, Feb 18, 2020 at 2:56 PM Pavel Stehule wrote:
> út 18. 2. 2020 v 6:03 odesílatel Amit Langote
> napsal:
>> I didn't send the patch, because it didn't handle the cases where a
>> simple expression consists of an inline-able function(s) in it, which
>> are better handled by a full-fledged
On Mon, 17 Feb 2020 at 15:14, Justin Pryzby wrote:
>
> On Mon, Feb 17, 2020 at 02:18:11PM +0900, Masahiko Sawada wrote:
> > Oops it seems to me that it's better to set error context after
> > tupindex = 0. Sorry for my bad.
>
> I take your point but did it differently - see what you think
>
> >
Hi all,
When recovery conflicts happen on the streaming replication standby,
the wait event of startup process is null when
max_standby_streaming_delay = 0 (to be exact, when the limit time
calculated by max_standby_streaming_delay is behind the last WAL data
receipt time is behind). Moreover the
Hello.
I understand that this is not for back-patching.
At Tue, 18 Feb 2020 16:44:59 +0900, Michael Paquier wrote
in
> On Thu, Dec 19, 2019 at 01:46:33PM +0900, Kyotaro Horiguchi wrote:
> > I found some similar places by grep'ing for windows version names the
> > whole source tree.
> >
> > -
On Tue, Feb 18, 2020 at 03:56:15PM +1300, Thomas Munro wrote:
> CREATE TYPE priv_testtype1 AS (a int, b text);
> +ERROR: relation 24844 deleted while still in use
> REVOKE USAGE ON TYPE priv_testtype1 FROM PUBLIC;
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.79923
>
On Tue, Feb 18, 2020 at 11:33 AM Andres Freund wrote:
>
> On 2020-02-18 11:20:17 +0530, Amit Kapila wrote:
> > Andres, any objections on proceeding with Kuntal's patch for
> > back-branches (10, 9.6 and 9.5)?
>
> Yes. In my past experiments that lead to *terrible* allocator
> performance due to
77 matches
Mail list logo
