At Wed, 25 Sep 2019 12:24:03 +0900, Michael Paquier wrote
in <20190925032403.gf1...@paquier.xyz>
> On Tue, Sep 24, 2019 at 02:48:16PM +0900, Kyotaro Horiguchi wrote:
> > Of course I found no *explicit* ones. But I found one
> > ereport(DEBUG1 in register_dirty_segment. So it will work at
> > leas
On Tue, Sep 24, 2019 at 11:25:30AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> ... I wonder if we should really continue to support
>> OpenSSL 0.9.8.
>
> Fair question, but post-rc1 is no time to be moving that goalpost
> for the v12 branch.
Yeah. I worked in the past with SUSE-based app
Hello.
709d003fbd hit this. Rebased.
Works fine but needs detailed verification and maybe further
cosmetic fixes.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 6be22b10c9df068c53c98ad3106e1bd88e07aeeb Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Thu, 5 Sep 2019
On Wed, Sep 25, 2019 at 1:47 PM Michael Paquier wrote:
>
> On Tue, Sep 24, 2019 at 11:36:40AM +0900, Amit Langote wrote:
> > Sure, thank you.
>
> And done with f5daf7f, back-patched down to 12.
Thanks again. :)
Regards,
Amit
Hello.
At Sat, 21 Sep 2019 13:06:25 +0300, Sergei Kornilov wrote in
<41171569060...@myt5-b646bde4b8f3.qloud-c.yandex.net>
> Hello
>
> Thank you for review! Can you please also check v4 version? v5 implements
> design suggested by Kyotaro Horiguchi-san, while v4 has another design. Which
> one
On Tue, Sep 24, 2019 at 11:53 PM Alvaro Herrera
wrote:
>
> I think the danger is what happens if a version of your plugin that was
> compiled with the older definition runs in a Postgres which has been
> recompiled with the new code. This has happened to me with previous
> unnoticed ABI breaks, a
On Tue, Sep 24, 2019 at 03:25:08PM +0900, Kyotaro Horiguchi wrote:
> In 0003, empty string and NULL are not digtinguishable in psql
> text output. It'd be better that the regression test checks that
> the return is actually NULL using "is NULL" or "\pset null
> ''" or something like.
For a patch w
On Tue, Sep 24, 2019 at 11:36:40AM +0900, Amit Langote wrote:
> Sure, thank you.
And done with f5daf7f, back-patched down to 12.
--
Michael
signature.asc
Description: PGP signature
On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule wrote:
> fixed
>
> Thank you for check. I am sending updated patch
>
Thanks for fixing all the comments.
Couple of suggestions:
-DROP DATABASE [ IF EXISTS ] name
+DROP DATABASE [ ( option
[, ...] ) ] [ IF EXISTS ] name
+
+where option can
be one of:
+
On Wed, Sep 18, 2019 at 9:30 AM Amit Kapila wrote:
>
> On Mon, Sep 16, 2019 at 11:24 PM Paul A Jungwirth
> wrote:
> >
> > On Mon, Sep 16, 2019 at 5:28 AM Amit Kapila wrote:
> > > I don't see this function on the master branch. Is this function name
> > > correct? Are you looking at some differ
On Tue, Sep 24, 2019 at 02:48:16PM +0900, Kyotaro Horiguchi wrote:
> Of course I found no *explicit* ones. But I found one
> ereport(DEBUG1 in register_dirty_segment. So it will work at
> least for the case where fsync request queue is full.
Exactly. I have not checked the patch in details, but I
On Tue, Sep 24, 2019 at 12:38:30PM -0300, Alvaro Herrera wrote:
> On 2019-Sep-24, Nikolay Shaplov wrote:
>> В письме от вторник, 24 сентября 2019 г. 9:25:54 MSK пользователь Alvaro
>> Herrera написал:
>>> 0003 looks useful, thanks for completing it. I think it would be a good
>>> idea to test inv
On Tue, Sep 24, 2019 at 04:49:11PM +0300, Nikolay Shaplov wrote:
> And then we came to a GUC variables. Because it we have five reloptions
> and we print them all each time we change something, there would be
> quite huge output.
Well, that depends on how you design your tests. The first versions
On Tue, Sep 24, 2019 at 6:22 PM Amit Kapila wrote:
> On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> >
> > Thank you for check. I am sending updated patch
> >
>
> Alvaro has up thread suggested some alternative syntax [1] for this
> patch, but I don't see any good argument to not go wi
>
> On 2019-Sep-20, Paul Guo wrote:
>
> > The patch series failed on Windows CI. I modified the Windows build file
> to
> > fix that. See attached for the v7 version.
>
> Thanks.
>
> Question about 0003. If we specify --skip-clean-shutdown and the cluter
> was not cleanly shut down, shouldn't we e
On Tue, Sep 24, 2019 at 11:33:35AM +0900, Michael Paquier wrote:
> Thanks for the review. Attached is the patch set I am planning to
> commit. I'll wait after the tag of this week as the first patch needs
> to go down to 9.6, the origin of the bug being 47167b7. The second
> patch would go only
At Tue, 24 Sep 2019 09:06:27 -0300, Alvaro Herrera
wrote in <20190924120627.GA12454@alvherre.pgsql>
> On 2019-Sep-24, Kyotaro Horiguchi wrote:
>
> > Sorry, it's not a boolean. A tristate value. From the definition
> > (Back, NoMove, Forward) = (-1, 0, 1), (dir1 == -dir2) if
> > NoMovement did no
On Tue, Sep 24, 2019 at 02:05:51PM +0200, Tomas Vondra wrote:
> The way I see it we can do either eager or lazy accounting. Eager might
> work better for aggregates with many contexts, but it does increase the
> overhead for the "regular" aggregates with just one or two contexts.
> Considering how
On Tuesday, September 24, 2019 5:41 PM (GMT+9), Fujii Masao wrote:
> On Thu, Sep 19, 2019 at 9:42 AM Jamison, Kirk
> wrote:
> >
> > On Wednesday, September 18, 2019 8:38 PM, Fujii Masao wrote:
> > > On Tue, Sep 17, 2019 at 10:44 AM Jamison, Kirk
> > >
> > > wrote:
> > > >
> > > > On Friday, Septe
On Tue, Sep 24, 2019 at 6:42 PM Ziga wrote:
> This also seems to be a problem for somewhat fringe case of subscriptions
> created with connect=false option.
> They cannot be dropped in an obvious way, without knowing the ALTER
> SUBSCRIPTION trick.
>
> For example:
>
> contrib_regression=# create
On Tue, Sep 24, 2019 at 5:25 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-09-24 16:31, Jeff Janes wrote:
> > I recently had to cut loose (pg_drop_replication_slot) a logical replica
> > that couldn't keep up and so was threatening to bring down the master.
> >
> > In mo
Alvaro Herrera writes:
> create table w (a point);
> # select * from w order by a fetch first 2 rows with ties;
> ERROR: could not identify an ordering operator for type point
> LINE 1: select * from w order by a fetch first 2 rows with ties;
> ^
> HINT: Use an
On Wed, Sep 25, 2019 at 1:22 AM Nikita Glukhov wrote:
> Attached another one-line patch that fixes incorrect number of distances used
> in pairingheap_SpGistSearchItem_cmp():
>
> -for (i = 0; i < so->numberOfOrderBys; i++)
> +for (i = 0; i < so->numberOfNonNullOrderBys; i++)
>
>
> This cha
Hi,
On September 24, 2019 3:09:28 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
>>> Andres Freund writes:
It's probably too big a hammer for this specific case, but I think
>at
some point we ought to stop using fixed size allocations
This also seems to be a problem for somewhat fringe case of subscriptions
created with connect=false option.
They cannot be dropped in an obvious way, without knowing the ALTER
SUBSCRIPTION trick.
For example:
contrib_regression=# create subscription test_sub connection
'dbname=contrib_regress
On 20.09.2019 0:15, Nikita Glukhov wrote:
On 19.09.2019 22:14, Alexander Korotkov wrote:
Pushed.
Attached patch fixes premature xs_orderbynulls[] assignment. The old value
of NULL flag, not the new, should be checked before pfree()ing the old value.
Attached another one-line patch that fixes
Andres Freund writes:
> On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> It's probably too big a hammer for this specific case, but I think at
>>> some point we ought to stop using fixed size allocations for this kind
>>> of work. Instead we should use something roughly
Hi,
On 2019-09-22 14:24:36 -0400, Tom Lane wrote:
> "Tsunakawa, Takayuki" writes:
> > In the following code in execTuples.c, shouldn' srcdesc point to the source
> > slot's tuple descriptor? The attached fix passes make check. What kind of
> > failure could this cause?
>
> Yeah, sure looks l
On 2019-Sep-24, Julien Rouhaud wrote:
> On Mon, Sep 9, 2019 at 5:03 PM Tom Lane wrote:
> > Whether we should bother back-patching a less capable stopgap fix
> > is unclear to me. Yeah, it's a bug that an index adviser can't
> > try a hypothetical BRIN index; but given that nobody noticed till
>
On 2019-09-24 09:18, Victor Wagner wrote:
> Problem is that some code in src/backend/libpq/be-secure-openssl.c
> assumes that if preprocessor symbols TLS1_1_VERSION and TLS1_2_VERSION
> are defined in the openssl headers, corresponding versions of TLS are
> supported by the library.
>
> It is not
On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-08-16 17:31:49 -0400, Tom Lane wrote:
> >> I fear that allowing pg_do_encoding_conversion to return strings longer
> >> than 1GB is just going to create failure cases somewhere else.
> >>
> >> However, it's certainly
Release 11 of the PostgreSQL Buildfarm client is now available
Apart from some bug fixes, there are to following features:
. Allow a list of branches as positional arguments to run_branches.pl
This overrides what is found in the config file. The list can't include
metabranches like ALL, n
On 2019-09-24 16:31, Jeff Janes wrote:
> I recently had to cut loose (pg_drop_replication_slot) a logical replica
> that couldn't keep up and so was threatening to bring down the master.
>
> In mopping up on the replica side, I couldn't just drop the
> subscription, because it couldn't drop the no
Thinking about the nearby thread[1] about overrunning MaxAllocSize
during encoding conversion, it struck me that another thing
we could usefully do to improve that situation is to be smarter
about what's the growth factor --- the existing one-size-fits-all
choice of MAX_CONVERSION_GROWTH = 4 is lea
On 2019-09-23 00:03, Tom Lane wrote:
> While we're whining about this, I find it very off-putting that
> the jsonpath stuff was inserted in the JSON functions section
> ahead of the actual JSON functions. I think it should have
> gone after them, because it feels like a barely-related interjection
Hi,
On 2019-09-12 16:42:46 -0400, Robert Haas wrote:
> The trouble starts with the header comment for AtAbort_Portals, which
> states that "At this point we run the cleanup hook if present, but we
> can't release the portal's memory until the cleanup call." At the time
> this logic was introduced
Andres Freund writes:
> On 2019-08-16 17:31:49 -0400, Tom Lane wrote:
>> I fear that allowing pg_do_encoding_conversion to return strings longer
>> than 1GB is just going to create failure cases somewhere else.
>>
>> However, it's certainly true that 4x growth is a pretty unlikely worst
>> case.
On 2019-Sep-20, Paul Guo wrote:
> The patch series failed on Windows CI. I modified the Windows build file to
> fix that. See attached for the v7 version.
Thanks.
Question about 0003. If we specify --skip-clean-shutdown and the cluter
was not cleanly shut down, shouldn't we error out instead of
On 2019-Sep-24, Antonin Houska wrote:
> Alvaro Herrera wrote:
> > If you don't have any strong dislikes for these changes, I'll push this
> > part and let you rebase the remains on top.
>
> No objections here.
oK, pushed. Please rebase the other parts.
I made one small adjustment: in read_lo
On Mon, Sep 23, 2019 at 5:13 PM Peter Geoghegan wrote:
> I attach version 17.
I attach a patch that applies on top of v17. It adds support for
deduplication within unique indexes. Actually, this is a snippet of
code that appeared in my prototype from August 5 (we need very little
extra code for t
On Thu, Sep 19, 2019 at 11:00 AM Jeff Davis wrote:
> On Wed, 2019-09-18 at 13:50 -0700, Soumyadeep Chakraborty wrote:
> > Hi Jeff,
>
> Hi Soumyadeep and Melanie,
>
> Thank you for the review!
>
> > max_stack_depth max level lazy (ms) eager (ms)
> (eage
> > r/lazy)
> > 2MB 82
On Sun, Jul 21, 2019 at 5:55 PM Tom Lane wrote:
> The FROM case could be improved perhaps, if somebody wanted to put
> time into it. You'd still need to be prepared to build a tuplestore,
> in case of rescan or backwards fetch; but in principle you could return
> rows immediately while stashing t
Heikki Linnakangas writes:
> On 22/08/2019 12:54, Adam Lee wrote:
>> My next thought is to call unlikely() here, but we don't have it...
> We do, actually, since commit aa3ca5e3dd in v10.
> Not sure it's worth the trouble here. Optimizing COPY in general would
> be good, even small speedups the
On Wed, Aug 21, 2019 at 9:53 AM Asif Rehman wrote:
> - BASE_BACKUP [PARALLEL] - returns a list of files in PGDATA
> If the parallel option is there, then it will only do pg_start_backup, scans
> PGDATA and sends a list of file names.
So IIUC, this would mean that BASE_BACKUP without PARALLEL ret
On Tue, Sep 24, 2019 at 5:41 AM Fujii Masao wrote:
> src/backend/replication/logical/proto.c
> action = pq_getmsgbyte(in);
> if (action != 'N')
> elog(ERROR, "expected new tuple but got %d",
> action);
>
> "%d" in the above message should be "%c" because the type of
> the variable "action"
Victor Wagner writes:
> I'm attaching patch which uses solution mentioned above.
> It seems that chedk for SSL_OP_NO_TLSvX_Y is redundant if
> we are checking for TLS_MAX_VERSION.
One thing I'm wondering is if it's safe to assume that TLS_MAX_VERSION
will be defined whenever these other symbols
On Mon, Sep 23, 2019 at 9:20 PM Finnerty, Jim wrote:
> If the function was moved to the FROM clause where it would be executed as a
> lateral cross join instead of a target list expression, how would this affect
> the cost-based positioning of the Gather?
I think you'd end up turning what is no
On Tue, Sep 24, 2019 at 6:22 PM Amit Kapila wrote:
>
> On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> >
> > Thank you for check. I am sending updated patch
> >
>
Session termination in case of drop database is solved.
Some typos:
+ /*
+ * Similar code to pg_terminate_backend, but we c
Hmm,
create table w (a point);
# select * from w order by a fetch first 2 rows with ties;
ERROR: could not identify an ordering operator for type point
LINE 1: select * from w order by a fetch first 2 rows with ties;
^
HINT: Use an explicit ordering operator or
On 2019-Sep-24, Nikolay Shaplov wrote:
> В письме от вторник, 24 сентября 2019 г. 9:25:54 MSK пользователь Alvaro
> Herrera написал:
>
> > 0003 looks useful, thanks for completing it. I think it would be a good
> > idea to test invalid values for each type of reloption too (passing
> > floating
Alvaro Herrera wrote:
> I spent a couple of hours on this patchset today. I merged 0001 and
> 0002, and decided the result was still messier than I would have liked,
> so I played with it a bit more -- see attached. I think this is
> committable, but I'm afraid it'll cause quite a few conflicts
Alvaro Herrera writes:
> ... I wonder if we should really continue to support
> OpenSSL 0.9.8.
Fair question, but post-rc1 is no time to be moving that goalpost
for the v12 branch.
> Anyway I suppose it's not impossible that third parties are still
> maintaining their 1.0.0 branch,
Another data
В письме от вторник, 24 сентября 2019 г. 9:25:54 MSK пользователь Alvaro
Herrera написал:
> 0003 looks useful, thanks for completing it. I think it would be a good
> idea to test invalid values for each type of reloption too (passing
> floating point to integers, strings to floating point, and s
rmrodrig...@carto.com writes:
> This commit is breaking some Postgis tests with custom types.
Hm, yeah, the code fails to consider the possibility that the function
returns a composite type.
For the moment I'm just going to make it punt if the function result
class isn't TYPEFUNC_SCALAR. In prin
On 2019-Sep-24, Victor Wagner wrote:
> Dear hackers,
>
> PostgreSQL 12 documentation states, that minimum required version of
> OpenSSL is 0.9.8. However, I was unable to сompile current
> PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
(Nice branch name.) I wonder if we should really co
I recently had to cut loose (pg_drop_replication_slot) a logical replica
that couldn't keep up and so was threatening to bring down the master.
In mopping up on the replica side, I couldn't just drop the subscription,
because it couldn't drop the nonexistent slot on the master and so refused
to wo
В Fri, 20 Sep 2019 20:58:27 +0900
Michael Paquier пишет:
Sorry I am really slow to answer... I hope it is not too late.
> The GUCs are also basically not necessary, as you can just replace the
> various WARNING calls (please don't call elog on anything which can be
> reached by the user!) by lo
Hello Amit,
{...]
If you agree with this, then why haven't you changed below check in patch:
+ if (partition_method != PART_NONE)
+ printf("partition method: %s\npartitions: %d\n",
+PARTITION_METHOD[partition_method], partitions);
This is exactly the thing bothering me. It won't be easy
On 20.09.2019 19:38, Alvaro Herrera wrote:
On 2019-Sep-19, Robert Haas wrote:
So, earlier in this thread, I suggested making this part of ALTER
TABLE, and several people seemed to like that idea. Did we have a
reason for dropping that approach?
Hmm, my own reading of that was to add tablespace
On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule wrote:
>
> Thank you for check. I am sending updated patch
>
Alvaro has up thread suggested some alternative syntax [1] for this
patch, but I don't see any good argument to not go with what he has
proposed. In other words, why we should prefer the c
On 2019-Sep-24, Michael Paquier wrote:
> I looked at that over the last couple of days, and done as attached.
> Well, the actual module is in 0003. I have added more comments to
> document the basic AM calls so as it can easier be used as a template
> for some other work, and tweaked a couple of
On 2019-Sep-24, Kyotaro Horiguchi wrote:
> Sorry, it's not a boolean. A tristate value. From the definition
> (Back, NoMove, Forward) = (-1, 0, 1), (dir1 == -dir2) if
> NoMovement did not exist. If it is not guranteed,
>
> (dir1 != 0 && dir1 == -dir2) ?
Maybe just add ScanDirectionIsOpposite(dir
On Tue, Sep 24, 2019 at 02:21:40PM +0900, Michael Paquier wrote:
On Wed, Jul 24, 2019 at 11:52:28PM +0200, Tomas Vondra wrote:
I think Heikki was asking about places with a lot of sub-contexts, which a
completely different issue. It used to be the case that some aggregates
created a separate con
This one just came up on IRC:
create table tltest(a integer, b text, c text, d text);
insert into tltest
select i, repeat('foo',100), repeat('foo',100), repeat('foo',100)
from generate_series(1,10) i;
set log_temp_files=0;
set client_min_messages=log;
select count(a+c) from (select a, c
Hi,
This commit is breaking some Postgis tests with custom types.
Here is a minimal repro (Postgis not required)
```
-- test custom types
create type t_custom_type AS (
valid bool,
reason varchar,
location varchar
);
create or replace function f_immutable_custom_type(i integer)
returns t_custom
On Fri, Sep 13, 2019 at 2:13 AM Robert Haas wrote:
>
/*
* Otherwise, do nothing to cursors held over from a previous
* transaction.
*/
if (portal->createSubid == InvalidSubTransactionId)
continue;
/*
* Do nothing to auto-held cursors. This is similar to the case of a
* cursor from a previous tra
On Tue, 24 Sep 2019 18:49:17 +0900
Michael Paquier wrote:
> On Tue, Sep 24, 2019 at 10:18:59AM +0300, Victor Wagner wrote:
> > PostgreSQL 12 documentation states, that minimum required version of
> > OpenSSL is 0.9.8. However, I was unable to сompile current
> > PGPRO_12_STABLE with OpenSSL 0.9.8
On Fri, Sep 20, 2019 at 6:20 PM Luis Carril
mailto:luis.car...@swarm64.com>> wrote:
Hello,
thanks for the comments!
* + if (tdinfo->filtercond || tbinfo->relkind == RELKIND_FOREIGN_TABLE)
filter condition is not implemented completely yet so the logic only work on
foreign table so I think it
On Tue, Sep 24, 2019 at 10:18:59AM +0300, Victor Wagner wrote:
> PostgreSQL 12 documentation states, that minimum required version of
> OpenSSL is 0.9.8. However, I was unable to сompile current
> PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
I can reproduce that with REL_12_STABLE and th
Hi,
src/backend/replication/logical/proto.c
action = pq_getmsgbyte(in);
if (action != 'N')
elog(ERROR, "expected new tuple but got %d",
action);
"%d" in the above message should be "%c" because the type of
the variable "action" is char? There are other log messages that
"%c" is used for s
On Fri, Sep 13, 2019 at 2:13 AM Robert Haas wrote:
>
> I've been studying At{Sub,}{Abort,Cleanup}_Portals() for the last few
> days and have come to the conclusion that the code is not entirely up
> to our usual standards. I believe that a good deal of the reason for
> this is attributable to the
At Tue, 24 Sep 2019 17:35:47 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190924.173547.226622711.horikyota@gmail.com>
> At Sun, 22 Sep 2019 23:02:04 -0300, Alvaro Herrera
> wrote in <20190923020204.GA2781@alvherre.pgsql>
> > On 2019-Sep-22, Dmitry Dolgov wrote:
> >
> > > >
On Thu, Sep 19, 2019 at 9:42 AM Jamison, Kirk wrote:
>
> On Wednesday, September 18, 2019 8:38 PM, Fujii Masao wrote:
> > On Tue, Sep 17, 2019 at 10:44 AM Jamison, Kirk
> > wrote:
> > >
> > > On Friday, September 13, 2019 10:06 PM (GMT+9), Fujii Masao wrote:
> > > > On Fri, Sep 13, 2019 at 9:51 P
At Sun, 22 Sep 2019 23:02:04 -0300, Alvaro Herrera
wrote in <20190923020204.GA2781@alvherre.pgsql>
> On 2019-Sep-22, Dmitry Dolgov wrote:
>
> > > I think multiplying two ScanDirections to watch for a negative result is
> > > pretty ugly:
> >
> > Probably, but the only alternative I see to check
> Could you provide a simple example of schema (tables with some
> policies and triggers), with the difference this generates for
> pg_dump, which shows your point?
Certainly; I've attached a bash script that can reproduce the issue
and the diff that it produces, here's the important part:
CR
On Mon, Sep 9, 2019 at 5:03 PM Tom Lane wrote:
>
> Alvaro Herrera from 2ndQuadrant writes:
> > On 2019-Sep-02, Tom Lane wrote:
> >> The right answer IMO is basically for the brinGetStats call to go
> >> away from brincostestimate and instead happen during plancat.c's
> >> building of the IndexOpt
Dear hackers,
PostgreSQL 12 documentation states, that minimum required version of
OpenSSL is 0.9.8. However, I was unable to сompile current
PGPRO_12_STABLE with OpenSSL 0.9.8j (from SLES 11sp4).
-fno-strict-aliasing -fwrapv -g -O2 -I../../../src/include -D_GNU_SOURCE
-I/usr/include/libxml2
On 2019-09-23 19:41, Alvaro Herrera wrote:
On 2019-Sep-23, Marina Polyakova wrote:
The branch REL9_4_STABLE (commit
8a17afe84be6fefe76d0d2f4d26c5ee075e64487)
has the same issue - according to the release table [2] it is still
supported, isn't it?...
Yeah, but pg_upgrade is in contrib/ in 9.4,
78 matches
Mail list logo
