On Tue, Aug 13, 2019 at 1:16 PM Kasahara Tatsuhito
wrote:
>
> Hi,
>
> I got following log messages when measured the heap truncating
> duration in a vacuum.
>
> =
> INFO: "dst": suspending truncate due to conflicting lock request
> INFO: "dst":
In your patch for copy.sgml:
ERROR_LIMIT 'limit_number'
I think this should be:
ERROR_LIMIT limit_number
(no single quote)
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Fri, Feb 14, 2020 at 12:47:19PM +0900, Fujii Masao wrote:
> logical_rewrite_truncate_v1.patch adds the description of
> LogicalRewriteTruncate into the doc. This needs to be
> back-patched to v10 where commit 249cf070e3 introduced
> LogicalRewriteTruncate event.
Indeed. You just be careful abo
Thank you very much everyone.
Improvement was confirmed even if PG12_STABLE was built with gcc 4.8.5.
* PG_12_STABLE
* gcc 4.8.5
postgres=# EXPLAIN (ANALYZE on, VERBOSE on, BUFFERS on)
select (2 * a) , (2 * b) , (2 * c), (2 * d), (2 * e)
from realtest;
QUERY PLAN
---
On Thu, Feb 13, 2020 at 02:22:36PM -0300, Ranier Vilela wrote:
> I just kept it, even if I duplicated the error message, the style was kept
> and in my opinion it is much more coherent and readable.
> But your solution is also good, and yes, it is worth it, because even with
> small benefits, the c
On Thu, 13 Feb 2020 at 13:16, Amit Kapila wrote:
>
> On Tue, Feb 11, 2020 at 9:13 PM Tom Lane wrote:
> >
> > I took a brief look through this patch. I agree with the fundamental
> > idea that we shouldn't need to use the heavyweight lock manager for
> > relation extension, since deadlock is not
On Thu, Feb 13, 2020 at 09:05:01PM +0530, Ashutosh Bapat wrote:
> That looks odd. Other sessions are able to see temporary tables of a given
> session because they are stored in the same catalog which is accessible to
> all the sessions. But ideally, a temporary table should be visible only to
> th
On Fri, Feb 14, 2020 at 1:04 AM Tom Lane wrote:
>
> Amit Langote writes:
> > On Thu, Feb 13, 2020 at 4:51 PM Amit Langote
> > wrote:
> >> I know I have made the mistake of not updating relnatts when I added
> >> relispartition, etc. to pg_class, only to be bitten by it in the form
> >> of seemi
Hello Fujii-san,
Thanks for your review!
On Wed, Jan 29, 2020 at 12:43 AM Fujii Masao
wrote:
> Isn't it better to add also xid8lt, xid8gt, xid8le, and xid8ge?
xid doesn't have these operators, probably to avoid confusion about
wraparound. But you're right, we should add them for xid8, especial
On Fri, Feb 14, 2020 at 3:47 AM Andres Freund wrote:
> On 2020-02-13 13:40:43 -0500, Tom Lane wrote:
> > ... and pushed. One other change I made beyond those suggested
> > was to push the zero-divide ereport's out-of-line as well.
>
> Thanks!
Thank you all.
I repeated some of the tests I did ea
Hi all,
createdb has a couple of issues with its quoting. For example take
that, which can be confusing:
$ createdb --lc-ctype="en_US.UTF-8';create table aa();select '1" popo
createdb: error: database creation failed: ERROR: CREATE DATABASE
cannot run inside a transaction block
The root of the
On 2020/02/13 16:30, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 03:35:50PM +0900, Fujii Masao wrote:
I found that the wait events "LogicalRewriteTruncate" and
"GSSOpenServer" are not documented. I'm thinking to add
them into doc separately if ok.
Nice catch. The ordering of the entries
On Thu, Feb 13, 2020 at 12:41:46PM +0100, Julien Rouhaud wrote:
> On Thu, Feb 13, 2020 at 12:14 PM Antonin Houska wrote:
>> I've noticed that convert_and_check_filename() is always passed false for the
>> "logAllowed" argument - someone probably forgot to remove the argument when
>> it
>> was dec
On Fri, 14 Feb 2020 at 08:52, Justin Pryzby wrote:
>
Thank you for updating the patch.
> On Thu, Feb 13, 2020 at 02:55:53PM +0900, Masahiko Sawada wrote:
> > You need to add a newline to follow the limit line lengths so that the
> > code is readable in an 80-column window. Or please run pgindent
On Sat, Feb 8, 2020 at 6:50 PM Peter Geoghegan wrote:
> My working assumption is that I only need to care about
> opclass-declared input data types (pg_opclass.opcintype), plus the
> corresponding collations -- the former can be used to lookup an
> appropriate pg_amproc entry (i.e. B-Tree support
On Wed, Jan 8, 2020 at 2:38 AM Heikki Linnakangas wrote:
> This makes the assumption that all Aggrefs or GroupingFuncs are at the
> top of the TargetEntry. That's not true, e.g.:
>
> select 0+sum(a) from foo group by b;
>
> I think find_aggregated_cols() and find_unaggregated_cols() should be
> m
On Tue, Jan 21, 2020 at 8:11 AM Andres Freund wrote:
> FWIW, I think we should just flat out delete all this logic, and replace
> it with a few explicit PrefetchBuffer() calls. Just by chance I
> literally just now sped up a VACUUM by more than a factor of 10, by
> manually prefetching buffers. At
Dear Hackers.
Thank you for an response.
I registered this entry in commifest of 2020-03.
# I registered in the security part, but if it is wrong, sincerely
apologize for this.
And I'd like to review show authority to ssl_ * later and discuss it
in a separate thread.
Best regards.
Moon.
On Thu,
On Thu, Feb 13, 2020 at 8:39 PM Fujii Masao wrote:
> On 2020/02/07 10:39, Amit Langote wrote:
> > On Fri, Feb 7, 2020 at 1:16 AM Fujii Masao
> > wrote:
> >> Yes, so I will review your patch getting rid of
> >> LOCK TABLE exception.
> >
> > Attached updated patch.
>
> Thanks! This patch basically
Hi,
On 2020-02-13 18:57:10 -0500, Tom Lane wrote:
> Maybe we could decide that the time for supporting easy updates from
> pre-9.1 is past, and just remove all the unpackaged-to-XXX scripts?
> Maybe even remove the "FROM version" option altogether.
Yea, that strikes me as a reasonable thing to do
On Thu, Feb 13, 2020 at 7:18 PM Thomas Munro wrote:
> ... (1) I'm pretty sure some systems would not be happy
> about that (see claims in this thread) ...
I poked a couple of people off-list and learned that, although the
Linux and FreeBSD systems I tried could do a million lseek(SEEK_END)
calls
I wrote:
> Andres Freund writes:
>> It seems to me that FROM UNPACKAGED shouldn't support trusted.
> Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> it given that "unpackaged" isn't magic in any way so far as extension.c
> is concerned. Maybe we could decide that the
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 --- is it really that
awful? If there is anything broken in it, wouldn't w
On Thu, Feb 13, 2020 at 02:55:53PM +0900, Masahiko Sawada wrote:
> You need to add a newline to follow the limit line lengths so that the
> code is readable in an 80-column window. Or please run pgindent.
For now I :set tw=80
> 2.
> I think that making initialization process of errcontext argumen
Hi,
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.
Have you audited how safe the create/upgrade scripts are against being
used to elevate privileges?
Especially with FROM UNPACKAGED it seems like i
pg_dump/restore fail to restore the ownership of an extension correctly:
in practice it'll always end up owned by whoever runs the restore
script. We've sort of averted our eyes from that up to now, because
it's not a big deal in a world where most extensions have to be
superuser-owned anyway. Bu
On Wed, 2020-02-12 at 21:51 -0800, Jeff Davis wrote:
> The new patch is basically just rebased -- a few other very minor
> changes.
I extracted out some minor refactoring of nodeAgg.c that I can commit
separately. That will make the main patch a little easier to review.
Attached.
* split build_ha
On Thu, Feb 13, 2020 at 2:14 PM Michael Paquier wrote:
>
> On Wed, Feb 12, 2020 at 09:46:48AM -0500, Tom Lane wrote:
> > Yeah; I don't think it's *that* unlikely for it to happen again. But
> > my own principal concern about this mirrors what somebody else already
> > pointed out: the one-major-r
pg_regress' --load-language option has been unused in the core code since
we introduced extensions in 9.1; all callers now use --load-extension
instead. It's a fairly safe bet that it's never been used by any non-core
code, since it could only work for languages listed in pg_pltemplate.
The last p
Yugo Nagata wrote
> Thank you for your suggestion! I agree that the feature to switch between
> normal materialized view and incrementally maintainable view is useful.
> We will add this to our ToDo list. Regarding its syntax,
> I would not like to add new keyword like NONINCREMENTAL, so how about
Hi,
On 2020-02-13 13:40:43 -0500, Tom Lane wrote:
> ... and pushed. One other change I made beyond those suggested
> was to push the zero-divide ereport's out-of-line as well.
Thanks!
> I did not do anything about adding unlikely() calls around the
> unrelated isinf tests in float.c. That see
... and pushed. One other change I made beyond those suggested
was to push the zero-divide ereport's out-of-line as well.
I did not do anything about adding unlikely() calls around the
unrelated isinf tests in float.c. That seemed to me to be a separate
matter, and I'm not quite convinced it'd b
Andres Freund writes:
> On 2020-02-13 16:25:25 +, Emre Hasegeli wrote:
>> And also this commit is changing the usage of unlikely() to cover
>> the whole condition. Using it only for the result is not semantically
>> correct. It is more than likely for the result to be infinite when
>> the in
Andres Freund writes:
> On February 13, 2020 8:30:45 AM PST, Tom Lane wrote:
>> I see some minor things I don't like here, eg float_*flow_error()
>> need some documentation as to why they exist. But I'll review,
>> fix those things up and then push.
> Would be good to mark them noreturn too.
Y
Hi,
On 2020-02-13 16:25:25 +, Emre Hasegeli wrote:
> And also this commit is changing the usage of unlikely() to cover
> the whole condition. Using it only for the result is not semantically
> correct. It is more than likely for the result to be infinite when
> the input is, or it to be 0 wh
Em qua., 12 de fev. de 2020 às 22:25, Tom Lane escreveu:
> Ranier Vilela writes:
> > Coverity detected a dead code in the src / interfaces / libpq / fe-auth.c
> > file, to correct it, a simplification was made and the oom_error goto was
> > removed, since it is clearly redundant and its presence
On Thu, Feb 13, 2020 at 9:26 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, Feb 13, 2020 at 4:13 AM Alexey Bashtanov
> wrote:
> >> Please could someone have a look at the patch attached?
> >> It's not just pedantry but rather based on a real-life example of
> >> someone reading an
Hi,
On February 13, 2020 8:30:45 AM PST, Tom Lane wrote:
>Emre Hasegeli writes:
Cool. Emre, any chance you could write a patch along those lines?
>
>> How about the one attached?
>
>I see some minor things I don't like here, eg float_*flow_error()
>need some documentation as to why they ex
Emre Hasegeli writes:
>>> Cool. Emre, any chance you could write a patch along those lines?
> How about the one attached?
I see some minor things I don't like here, eg float_*flow_error()
need some documentation as to why they exist. But I'll review,
fix those things up and then push.
> On Feb 13, 2020, at 3:44 AM, Suraj Kharage
> wrote:
>
> Hi,
>
> I have spent some time reviewing the patches and overall it looks good to me.
>
> However, I have few cosmetic review comments for 0003 patch as below;
>
> 1:
> +++ b/src/backend/utils/hash/hashfn.c
> @@ -16,15 +16,14 @@
>
> > > > For most places it'd probably end up being easier to read and to
> > > > optimize if we just wrote them as
> > > > if (unlikely(isinf(result)) && !isinf(arg))
> > > > float_overflow_error();
> > > > and when needed added a
> > > > else if (unlikely(result == 0) && arg1 != 0.0)
> > > >
"David G. Johnston" writes:
> On Thu, Feb 13, 2020 at 4:13 AM Alexey Bashtanov wrote:
>> Please could someone have a look at the patch attached?
>> It's not just pedantry but rather based on a real-life example of
>> someone reading and being not sure
>> whether e.g. joins can be used in there.
Amit Langote writes:
> On Thu, Feb 13, 2020 at 4:51 PM Amit Langote wrote:
>> I know I have made the mistake of not updating relnatts when I added
>> relispartition, etc. to pg_class, only to be bitten by it in the form
>> of seemingly random errors/crashes. Is that why?
> Sorry for not having
On 2020-Feb-13, Thomas Munro wrote:
> On Thu, Feb 13, 2020 at 5:30 AM Alvaro Herrera
> wrote:
> > On 2020-Feb-12, Thomas Munro wrote:
> > > Hmm. Well, on Unix we have to choose between "tell me the size but
> > > also change the position that I either don't care about or have to
> > > undo", an
Julien Rouhaud writes:
> On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote:
>>> When making build system changes that risk breaking the MSVC build system,
>>> it's useful to be able to run the part of the MSVC build tools that read the
>>> makefiles and produce the project files und
On Thu, Feb 13, 2020 at 6:40 PM Fujii Masao
wrote:
> Hi,
>
> TRUNCATE command on the temporary tables of other sessions fails
> with the following error. This behavior looks expected to me.
>
> ERROR: cannot truncate temporary tables of other sessions
>
> However I found that LOCK TABLE and
Peter Eisentraut writes:
> GCC reports various instances of
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> in ECPG test files. This is because void* and long are
čt 13. 2. 2020 v 14:40 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-12-21 07:47, Peter Eisentraut wrote:
> > When updating a table row with generated columns, we only need to
> > recompute those generated columns whose base columns have changed in
> > this upda
On Thu, Feb 13, 2020 at 11:13:32AM +, Alexey Bashtanov wrote:
> Hello,
>
> Currently the documentation says that one can put "a list of table
> expressions"
> after FROM in UPDATE or after USING in DELETE.
> However, "table expression" is defined as a complex of
> FROM, WHERE, GROUP BY and HAV
On Thu, Feb 13, 2020 at 4:13 AM Alexey Bashtanov wrote:
> Hello,
>
> Currently the documentation says that one can put "a list of table
> expressions"
> after FROM in UPDATE or after USING in DELETE.
> However, "table expression" is defined as a complex of
> FROM, WHERE, GROUP BY and HAVING claus
On Thu, Feb 13, 2020 at 12:52 AM Michael Paquier
wrote:
> On Wed, Feb 12, 2020 at 01:59:05PM -0300, Fabrízio de Royes Mello wrote:
> > In parallel mode it's firing the EventTrigger and it can't be happen.
> > Poking around it I did some test with attached just to leave
> EventTriggers
> > in pend
GCC reports various instances of
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
and MSVC equivalently
warning C4312: 'type cast': conversion from 'int' to 'void *' of
On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote:
> On 2020-02-13 13:04, Michael Paquier wrote:
> > On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
> > > When making build system changes that risk breaking the MSVC build system,
> > > it's useful to be able to run
On 2019-12-21 07:47, Peter Eisentraut wrote:
When updating a table row with generated columns, we only need to
recompute those generated columns whose base columns have changed in
this update and keep the rest unchanged. This can result in a
significant performance benefit (easy to reproduce for
čt 13. 2. 2020 v 14:11 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Thu, Feb 13, 2020 at 10:15:14AM +0100, Pavel Stehule wrote:
> >
> > I tested last set of patches.
>
> Thanks a lot for testing!
>
> > I like patch 0006 - filling gaps by NULLs - it fixed my objections if I
> >
On 2020-02-13 13:04, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project
Sounds like a fine idea. But personally I would prefer it without the <>
around the it, just a url on a line by itself. I think it would be clearer,
look cleaner, and be easier to select to copy/paste elsewhere.
On Tue., Feb. 11, 2020, 02:42 Peter Eisentraut, <
peter.eisentr...@2ndquadrant.com> wr
> On Thu, Feb 13, 2020 at 10:15:14AM +0100, Pavel Stehule wrote:
>
> I tested last set of patches.
Thanks a lot for testing!
> I like patch 0006 - filling gaps by NULLs - it fixed my objections if I
> remember correctly. Patch 0005 - polymorphic subscribing - I had not a
> idea, what is a use c
Hi,
TRUNCATE command on the temporary tables of other sessions fails
with the following error. This behavior looks expected to me.
ERROR: cannot truncate temporary tables of other sessions
However I found that LOCK TABLE and DROP TABLE commands on
the temporary tables of other sessions are
On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
> When making build system changes that risk breaking the MSVC build system,
> it's useful to be able to run the part of the MSVC build tools that read the
> makefiles and produce the project files under a not-Windows platform. This
On Thu, Feb 13, 2020 at 10:02:31AM +0100, Peter Eisentraut wrote:
> On 2020-02-12 06:28, Michael Paquier wrote:
>> Now, don't we need to care about durable_rename() and make the
>> panic-like failure an optional choice? From what I can see, this
>> routine is used now in the backend for pg_basebac
On Thu, Feb 13, 2020 at 12:15:39PM +0100, Antonin Houska wrote:
> I've noticed that convert_and_check_filename() is always passed false for the
> "logAllowed" argument - someone probably forgot to remove the argument when it
> was decided that log files are no longer accepted. If the argument was
Hi,
I have spent some time reviewing the patches and overall it looks good to
me.
However, I have few cosmetic review comments for 0003 patch as below;
1:
+++ b/src/backend/utils/hash/hashfn.c
@@ -16,15 +16,14 @@
* It is expected that every bit of a hash function's 32-bit result is
* as ra
On Thu, Feb 13, 2020 at 12:14 PM Antonin Houska wrote:
>
> I've noticed that convert_and_check_filename() is always passed false for the
> "logAllowed" argument - someone probably forgot to remove the argument when it
> was decided that log files are no longer accepted. If the argument was
> remo
On 2020/02/07 10:39, Amit Langote wrote:
On Fri, Feb 7, 2020 at 1:16 AM Fujii Masao wrote:
On 2020/02/03 14:26, Amit Langote wrote:
On Mon, Feb 3, 2020 at 2:07 PM Fujii Masao wrote:
On 2020/02/03 11:05, Amit Langote wrote:
Okay. How about the attached?
Thanks for the patches! You adde
On Thu, Feb 13, 2020 at 5:39 PM Julien Rouhaud wrote:
> On Tue, Feb 11, 2020 at 10:06:17PM +0530, Ashutosh Bapat wrote:
> > On Tue, Feb 11, 2020 at 8:27 AM Andy Fan
> wrote:
> >
> > > On Tue, Feb 11, 2020 at 12:22 AM Ashutosh Bapat <
> > > ashutosh.bapat@gmail.com> wrote:
> > >
> > >>>
> > >
I've noticed that convert_and_check_filename() is always passed false for the
"logAllowed" argument - someone probably forgot to remove the argument when it
was decided that log files are no longer accepted. If the argument was removed,
the function would become a bit simpler, see the patch.
--
A
Hello,
Currently the documentation says that one can put "a list of table
expressions"
after FROM in UPDATE or after USING in DELETE.
However, "table expression" is defined as a complex of
FROM, WHERE, GROUP BY and HAVING clauses [1].
The thing one can list in the FROM clause in a comma-separat
When making build system changes that risk breaking the MSVC build
system, it's useful to be able to run the part of the MSVC build tools
that read the makefiles and produce the project files under a
not-Windows platform. This part does not really depend on anything
particular to Windows, so i
On 2020/02/13 18:14, Julien Rouhaud wrote:
On Thu, Feb 13, 2020 at 09:56:38AM +0100, Peter Eisentraut wrote:
Attached is a demo patch that adds a placeholder %b for log_line_prefix (not
in the default setting) that contains the backend type, the same that you
see in pg_stat_activity and in th
On Tue, Feb 11, 2020 at 10:06:17PM +0530, Ashutosh Bapat wrote:
> On Tue, Feb 11, 2020 at 8:27 AM Andy Fan wrote:
>
> > On Tue, Feb 11, 2020 at 12:22 AM Ashutosh Bapat <
> > ashutosh.bapat@gmail.com> wrote:
> >
> >>>
> >>> [PATCH] Erase the distinctClause if the result is unique by
> >>> defi
Hi
čt 19. 12. 2019 v 15:20 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Nov 10, 2019 at 01:32:08PM +0100, Dmitry Dolgov wrote:
> >
> > > I had to write new assignment logic reusing only some parts of
> setPath(),
> > > because the loop in setPath() should be broken on ever
On Thu, Feb 13, 2020 at 09:56:38AM +0100, Peter Eisentraut wrote:
> Attached is a demo patch that adds a placeholder %b for log_line_prefix (not
> in the default setting) that contains the backend type, the same that you
> see in pg_stat_activity and in the ps status. I would have found this
> occ
On 2020-02-13 04:38, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 11:28:05AM +0900, Kyotaro Horiguchi wrote:
I think it is reasonable.
Indeed, that makes sense to me as well. I am adding Peter Eisentraut
in CC as the author/committer of 8a3d942 to comment on that.
I'm OK with changing tha
On 2020-02-12 06:28, Michael Paquier wrote:
Now, don't we need to care about durable_rename() and make the
panic-like failure an optional choice? From what I can see, this
routine is used now in the backend for pg_basebackup to rename
temporary history files or partial WAL segments.
durable_re
Attached is a demo patch that adds a placeholder %b for log_line_prefix
(not in the default setting) that contains the backend type, the same
that you see in pg_stat_activity and in the ps status. I would have
found this occasionally useful when analyzing logs, especially if you
have a lot of
On Thu, Feb 13, 2020 at 8:32 AM Amit Langote wrote:
>
> On Thu, Feb 13, 2020 at 10:30 AM Kyotaro Horiguchi
> wrote:
> > At Mon, 10 Feb 2020 14:32:44 +0900, Amit Langote
> > wrote in
> > > Agree that ObjectIsUserObject(oid) is easier to read than oid >=
> > > FirstNormalObject. I would have not
On Thu, Feb 13, 2020 at 4:51 PM Amit Langote wrote:
> On Thu, Feb 13, 2020 at 3:23 AM Justin Pryzby wrote:
> > Forking this thread for two tangential patches which I think are more
> > worthwhile than the original topic's patch.
> > https://www.postgresql.org/message-id/20200207143935.GP403%40tel
On Thu, Feb 13, 2020 at 04:51:01PM +0900, Amit Langote wrote:
> On Thu, Feb 13, 2020 at 3:23 AM Justin Pryzby wrote:
> > Forking this thread for two tangential patches which I think are more
> > worthwhile than the original topic's patch.
> > https://www.postgresql.org/message-id/20200207143935.GP
On Thu, Feb 13, 2020 at 04:51:01PM +0900, Amit Langote wrote:
> I would think the answer to that would be related to the answer of why
> you think we need this assert in the first place?
Taking this thread independently, and even after reading the thread
mentioned upthread, I still don't quite und
80 matches
Mail list logo
