On 11 April 2017 at 12:53, Michael Paquier wrote:
> On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote:
>> On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote:
>>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
Why bother with the 'rte' variable at all if it's only used f
Petr Jelinek writes:
> On 05/05/17 16:56, Tom Lane wrote:
>> So the comment should be something like "if the column is unchanged,
>> we should not attempt to access its value beyond this point. To
>> help catch any such attempts, set the string to NULL" ?
> Yes that sounds about right. We don't
On 05/05/17 16:56, Tom Lane wrote:
> Petr Jelinek writes:
>> On 05/05/17 06:50, Tom Lane wrote:
>>> Actually, looking around a bit there, it's not even clear why
>>> we should be booby-trapping the value of an unchanged column in
>>> the first place. So I'd say that not only is the code dubious
>
Petr Jelinek writes:
> On 05/05/17 06:50, Tom Lane wrote:
>> Actually, looking around a bit there, it's not even clear why
>> we should be booby-trapping the value of an unchanged column in
>> the first place. So I'd say that not only is the code dubious
>> but the comment is inadequate too.
> H
On 05/05/17 06:50, Tom Lane wrote:
> Haribabu Kommi writes:
>> I am getting a compiler warning when I build the latest HEAD PostgreSQL with
>> visual studio 2017.
>> The code at the line is,
>> tuple->values[i] = (char *) (Size)0xdeadbeef; /* make bad usage more obvious
>> */
>
> Yeah, you're no
Haribabu Kommi writes:
> I am getting a compiler warning when I build the latest HEAD PostgreSQL with
> visual studio 2017.
> The code at the line is,
> tuple->values[i] = (char *) (Size)0xdeadbeef; /* make bad usage more obvious
> */
Yeah, you're not the first to complain about this. To my min
I am getting a compiler warning when I build the latest HEAD PostgreSQL with
visual studio 2017.
src/backend/replication/logical/proto.c(482): warning C4312: 'type cast':
conversion from 'unsigned int' to 'char *' of greater size
Details of the warning is available in the link [1].
The code at t
On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote:
> On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote:
>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>>> Why bother with the 'rte' variable at all if it's only used for the
>>> Assert()ing the rtekind?
>>
>> That was propo
On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Why bother with the 'rte' variable at all if it's only used for the
>> Assert()ing the rtekind?
>
> That was proposed a few messages back. I don't like it because it makes
>
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Why bother with the 'rte' variable at all if it's only used for the
> Assert()ing the rtekind?
That was proposed a few messages back. I don't like it because it makes
these functions look different from the other scan-cost-es
Robert Haas writes:
> On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier
> wrote:
>> On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
>>> I wonder if we shouldn't just do
>>> ...
>>> and eat the "useless" calculation of rte.
> -1 from me. I'm not a big fan of useless calculation just because it
Tom Lane writes:
> I wonder if we shouldn't just do
>
> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> -#ifdef USE_ASSERT_CHECKING
> rte = planner_rt_
On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier
wrote:
> On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
>> I wonder if we shouldn't just do
>>
>> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
>> ListCell *lc;
>>
>> /* Should only be applied to base relations that are s
On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
> I wonder if we shouldn't just do
>
> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> -#ifdef USE_ASSE
David Rowley writes:
> On 8 April 2017 at 04:42, Tom Lane wrote:
>> BTW, is it really true that only these two places produce such warnings
>> on MSVC? I see about three dozen uses of PG_USED_FOR_ASSERTS_ONLY in our
>> tree, and I'd have expected all of those places to be causing warnings on
>>
On 8 April 2017 at 04:42, Tom Lane wrote:
> I'd be happier with something along the line of
>
> RangeTblEntry *rte;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> rte = planner_rt_fetch(re
Michael Paquier writes:
> Bah. This actually fixes nothing. Attached is a different patch that
> really addresses the problem, by removing the variable because we
> don't want planner_rt_fetch() to run for non-Assert builds.
I don't really like any of these fixes, because they take the code
furth
On Fri, Apr 7, 2017 at 12:38 AM, Michael Paquier
wrote:
> On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier
> wrote:
>> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote:
>>> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY,
>>> because it tends to confuse pgindent.)
>>
>> I would
On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier
wrote:
> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote:
>> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY,
>> because it tends to confuse pgindent.)
>
> I would be incline to just do that, any other solution I can think of
> is
On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote:
> Michael Paquier writes:
>> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can
>> generate warnings. Here is for example with MSVC:
>> src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' :
>> unreferenced local vari
Michael Paquier writes:
> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can
> generate warnings. Here is for example with MSVC:
> src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' :
> unreferenced local variable [C:\Users\ioltas\git\postgres\postgres.vcxproj]
>
On Tue, Apr 4, 2017 at 7:03 PM, David Rowley
wrote:
> On 4 April 2017 at 16:22, Michael Paquier wrote:
>> Hi all,
>>
>> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can
>> generate warnings. Here is for example with MSVC:
>> src/backend/optimizer/path/costsize.c(4520): warning
On 4 April 2017 at 16:22, Michael Paquier wrote:
> Hi all,
>
> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can
> generate warnings. Here is for example with MSVC:
> src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' :
> unreferen
> ced local variable [C:\Users\
Hi all,
In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can
generate warnings. Here is for example with MSVC:
src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' : unreferen
ced local variable [C:\Users\ioltas\git\postgres\postgres.vcxproj]
src/backend/optimizer/pa
On Thu, Mar 9, 2017 at 4:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> I tried a non-cassert compile on a machine that has a pickier compiler
>> than my laptop, and got:
>
>> costsize.c: In function ‘set_tablefunc_size_estimates’:
>> costsize.c:4574:17: error: variable ‘rte’ set but not used
>>
Robert Haas writes:
> I tried a non-cassert compile on a machine that has a pickier compiler
> than my laptop, and got:
> costsize.c: In function ‘set_tablefunc_size_estimates’:
> costsize.c:4574:17: error: variable ‘rte’ set but not used
> [-Werror=unused-but-set-variable]
> That appears to be
I tried a non-cassert compile on a machine that has a pickier compiler
than my laptop, and got:
costsize.c: In function ‘set_tablefunc_size_estimates’:
costsize.c:4574:17: error: variable ‘rte’ set but not used
[-Werror=unused-but-set-variable]
That appears to be a legitimate gripe. Perhaps:
di
On Dec 24, 2016 01:21, "Bruce Momjian" wrote:
I am seeing this compiler warning in the 9.4 branch:
9.4: basebackup.c:1284:6: warning: variable 'wait_result' set but not
used [-Wunused-but-set-variable]
This is on Debian Jessie with gcc version 4.9.2. It is from this commit:
commit f
I am seeing this compiler warning in the 9.4 branch:
9.4: basebackup.c:1284:6: warning: variable 'wait_result' set but not used
[-Wunused-but-set-variable]
This is on Debian Jessie with gcc version 4.9.2. It is from this commit:
commit f6508827afe76b2c3735a9ce073620e708d60c79
Tom Lane wrote:
> I do not think you should assume that the compiler is smart enough to
> deduce that, nor that all compilers even know ereport(ERROR) doesn't
> return. Personally I don't see the point of the "type" variable at
> all, anyway. I would have written this as
>
> [code]
Makes sense
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> I'm getting the following compiler warning (using nondefault
>> optimization options):
>> objectaddress.c: In function 'read_objtype_from_string':
>> objectaddress.c:2309:9: error: 'type' may be used uninitialized in this
>> function [-Werror=may
Peter Eisentraut wrote:
> I'm getting the following compiler warning (using nondefault
> optimization options):
>
> objectaddress.c: In function 'read_objtype_from_string':
> objectaddress.c:2309:9: error: 'type' may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> return
I'm getting the following compiler warning (using nondefault
optimization options):
objectaddress.c: In function 'read_objtype_from_string':
objectaddress.c:2309:9: error: 'type' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
return type;
The comment for the function s
David Rowley writes:
> I've attached a small patch to fix new compiler warning which is new as of
> 65c5fcd3
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Hi,
I've attached a small patch to fix new compiler warning which is new as of
65c5fcd3
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
amcostestimate_cast.patch
Description: Binary data
--
Sent via pgsql-hackers maili
Peter Geoghegan writes:
> Commit 7e2a18a9 must have caused this compiler warning which I now see
> on the master branch with my standard release build settings:
[ scratches head... ] Dunno why my compiler didn't complain about that.
Will fix it in a bit.
regards, tom lan
Commit 7e2a18a9 must have caused this compiler warning which I now see
on the master branch with my standard release build settings:
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv
Petr Jelinek writes:
> my compiler complains about overflow in xlog.c.
Yeah, Peter E. reported this yesterday. Since Heikki didn't do
anything about that yet, I pushed your fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Hi,
my compiler complains about overflow in xlog.c.
There is variable defined as char partialfname[MAXFNAMELEN]; but is used
as snprintf(partialfname, MAXPGPATH, "%s.partial", origfname);
There is no practical issue as the actual filename length is never over
MAXFNAMELEN even with the .parti
David Rowley wrote:> On Mon, Nov 10, 2014 at 4:31 PM,
Peter Geoghegan wrote:
>> I see this when I build at -O2 from master's tip:
>> brin_revmap.c: In function ‘brinRevmapExtend’:
>> brin_revmap.c:113:14: error: variable ‘mapBlk’ set but not used
>> [-Werror=unused-but-set-variable]
>> Block
On Mon, Nov 10, 2014 at 4:31 PM, Peter Geoghegan wrote:
> I see this when I build at -O2 from master's tip:
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -fexcess-
I see this when I build at -O2 from master's tip:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -Werror -I../../../../src/include
-D_FORTIFY_SOURC
W dniu 19.07.2013 02:42, Tom Lane pisze:
> Hm, what compiler version are you using? I've never seen such a
> warning (and that code hasn't changed in some time).
gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC)
Regards,
Karol
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Karol Trzcionka writes:
> in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41),
> I've noticed the compiler warnings in src/backend/utils/mb/conv.c
Hm, what compiler version are you using? I've never seen such a warning
(and that code hasn't changed in some time).
I agree the c
Hello,
in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41),
I've noticed the compiler warnings in src/backend/utils/mb/conv.c
conv.c: In function ‘UtfToLocal’:
conv.c:252:23: error: ‘iutf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
...
conv.c: In func
Magnus Hagander wrote:
> On Thu, Feb 3, 2011 at 04:40, Bruce Momjian wrote:
> > I am seeing the following compiler warning for the past few days:
> >
> > ? ? ? ?basebackup.c:213: warning: variable `ptr' might be clobbered by
> > ? ? ? ?`longjmp' or `vfork'
> >
> > and I see this comment in the fil
On Thu, Feb 3, 2011 at 04:40, Bruce Momjian wrote:
> I am seeing the following compiler warning for the past few days:
>
> basebackup.c:213: warning: variable `ptr' might be clobbered by
> `longjmp' or `vfork'
>
> and I see this comment in the file:
>
> /*
> * Actually
I am seeing the following compiler warning for the past few days:
basebackup.c:213: warning: variable `ptr' might be clobbered by
`longjmp' or `vfork'
and I see this comment in the file:
/*
* Actually do a base backup for the specified tablespaces.
*
Jeff Davis writes:
> A little while ago, I saw a compiler warning creep in:
> In file included from gram.y:11202:
> scan.c: In function âyy_try_NUL_transâ:
> scan.c:15765: warning: unused variable âyygâ
Yeah, this is a bogosity in the current release of "flex".
http://sourceforge.net/trac
A little while ago, I saw a compiler warning creep in:
In file included from gram.y:11202:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:15765: warning: unused variable ‘yyg’
I know there were some changes to minimum versions, but I think I have
those versions (listed below). I don't know if oth
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v Ät 28. 05. 2009 v 11:42 -0400:
>> The proposed signature change on psql_completion
>> is going to replace a warning on your system with outright failures on
>> other people's.
> I check readline and definition is still same at least from 5.0 version.
> I
Tom Lane píše v čt 28. 05. 2009 v 11:57 -0400:
> ).
>
> AFAICS, Sun's compiler is just too stupid and shouldn't be emitting
> this warning. Perhaps the right response is to file a bug report
> against the compiler.
I checked it and it is already know bug. It is new lint style check in
Sun Studi
Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
> Zdenek Kotala writes:
> > I attached another cleanup patch which fixes following warnings reported
> > by Sun Studio:
>
> I'm not too impressed with any of these. The proposed added
> initializers just increase future maintenance effort without s
Michael Meskes writes:
> I have to admit that those version look strikingly unsimilar to me. There is
> no
> reference to Rhs[N] in our macro at all. But then I have no idea whether this
> is needed.
The default version of the macro is intended to track both the starting
and ending locations of
Zdenek Kotala writes:
> I attached another cleanup patch which fixes following warnings reported
> by Sun Studio:
I'm not too impressed with any of these. The proposed added
initializers just increase future maintenance effort without solving
any real problem (since the variables are required by
Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200:
> On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> > Problem is with YYLLOC_DEFAULT. When I look on macro definition
> >
> > #define YYLLOC_DEFAULT(Current, Rhs, N) \
> > Current.first_line = Rhs[1].first_line;
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> Problem is with YYLLOC_DEFAULT. When I look on macro definition
>
> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> Current.first_line = Rhs[1].first_line; \
> Current.first_column = Rhs[1].first_column;\
> Cur
Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200:
> On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
> > I attached another cleanup patch which fixes following warnings reported
> > by Sun Studio:
> > ...
> > "preproc.c", line 39569: warning: pointer expression or its operand do n
On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
> I attached another cleanup patch which fixes following warnings reported
> by Sun Studio:
> ...
> "preproc.c", line 39569: warning: pointer expression or its operand do not
> point to the same object yyerror_range, result is undefine
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
"zic.c", line 1534: warning: const object should have initializer: tzh0
"dynloader.c", line 7: warning: empty translation unit
"pgstat.c", line 666: warning: const object should have initializer: all_zeroes
"pg
On Thursday 21 May 2009 14:29:51 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
> >> Hmm, the patch looks fine to me. The strings are marked with
> >> gettext_noop() in the array, and passed through _() when used in errmsg.
> >
> > But his
Peter Eisentraut writes:
> On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
>> Hmm, the patch looks fine to me. The strings are marked with
>> gettext_noop() in the array, and passed through _() when used in errmsg.
> But his patch changes that to
> errhint("%s", _(wentry->drophint_msg
On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote:
> Peter Eisentraut wrote:
> > Note that applying this patch would introduce a double-translation issue
> > of the sort that you had complained about a while ago. I'm unsure which
> > way to proceed here.
>
> Hmm, the patch looks fine to me
Peter Eisentraut wrote:
Note that applying this patch would introduce a double-translation issue of
the sort that you had complained about a while ago. I'm unsure which way to
proceed here.
Hmm, the patch looks fine to me. The strings are marked with
gettext_noop() in the array, and passed t
On Wednesday 20 May 2009 16:24:21 Tom Lane wrote:
> Heikki Linnakangas writes:
> > Hmm, it is a false alarm, but would be nice to have a warning-free
> > build. I don't see that warning here on gcc 4.3.3 by default, but I do
> > when I set -Wformat-security. I presume you had that set as well.
>
>
Heikki Linnakangas writes:
> Hmm, it is a false alarm, but would be nice to have a warning-free
> build. I don't see that warning here on gcc 4.3.3 by default, but I do
> when I set -Wformat-security. I presume you had that set as well.
Would it be worth having configure probe for that switch a
Fujii Masao wrote:
I encountered the following compiler warning in 8.4dev.
Attached is the patch to fix this problem. Is this worth committing?
--
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:606: warning: format not a string literal and no format arguments
-
Hi,
I encountered the following compiler warning in 8.4dev.
Attached is the patch to fix this problem. Is this worth committing?
--
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:606: warning: format not a string literal and no format arguments
--
$
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We could stick a volatile on it but I'd like to find out why this
> >> particular variable seems to need that.
>
> > You ready for this; changing 'bool' to 'int' supressed the warning:
> > int fast = PG_GETARG_BOOL(1);
>
>
Bruce Momjian writes:
> Tom Lane wrote:
>> We could stick a volatile on it but I'd like to find out why this
>> particular variable seems to need that.
> You ready for this; changing 'bool' to 'int' supressed the warning:
> int fast = PG_GETARG_BOOL(1);
Well, that's a compiler bug :-(
Tom Lane wrote:
> Bruce Momjian writes:
> > Any idea why I am seeing this warning with the new pg_start_backup()
> > 'fast' flag?
>
> > xlog.c:6917: warning: variable `fast' might be clobbered by
> > `longjmp' or `vfork'
>
> > The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is wi
Bruce Momjian writes:
> Any idea why I am seeing this warning with the new pg_start_backup()
> 'fast' flag?
> xlog.c:6917: warning: variable `fast' might be clobbered by
> `longjmp' or `vfork'
> The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc
> version 2.95.3.
Th
Any idea why I am seeing this warning with the new pg_start_backup()
'fast' flag?
xlog.c:6917: warning: variable `fast' might be clobbered by
`longjmp' or `vfork'
The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc
version 2.95.3.
--
Bruce Momjian http
On Tue, Feb 03, 2009 at 04:06:39PM -0300, Alvaro Herrera wrote:
> Note that spoonbill is still red. This animal is special because it
> uses some peculiar malloc flags.
Not just spoonbill, five of them are. Without access to a failing machine this
is difficult to debug. I found some missing error
Michael Meskes wrote:
> On Mon, Feb 02, 2009 at 02:56:18PM -0500, Tom Lane wrote:
> > CVS HEAD is producing
> > ...
>
> Thanks for the note, I missed this copy&paste error of mine. Fixed in HEAD.
> This should alos make the buildfarm green again.
Note that spoonbill is still red. This animal is
On Mon, Feb 02, 2009 at 02:56:18PM -0500, Tom Lane wrote:
> CVS HEAD is producing
> ...
Thanks for the note, I missed this copy&paste error of mine. Fixed in HEAD.
This should alos make the buildfarm green again.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|C
CVS HEAD is producing
execute.c: In function 'ecpg_store_result':
execute.c:394: warning: 'act_tuple' may be used uninitialized in this function
It looks to me like this is an actual bug, not just the compiler being
insufficiently smart to prove the variable is set before use.
It's nothing but unused definitions. PostgreSQL7.1 compiles and works for me.
I got following warnings for PL/PgSQL
make[2]: `/opt/rh7/postgresql/postgresql-7.1/src/pl'
make[3]: `/opt/rh7/postgresql/postgresql-7.1/src/pl/plpgsql'
make -C src all
make[4]: `/opt/rh7/postgresql/postgresql-7.1/src/pl
78 matches
Mail list logo