:
reported to the client (with the server log of course saying something
different). So I gave up and left that behavior separate.
Comments? Should we do this, or leave things alone?
regards, tom lane
binLODlX7W7vf.bin
Description: dependency-notices-1.patch.gz
--
Sent
from DB2 to PG?)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
(It's also worth asking where the import is coming from. Who implements
the spec syntax anyway? DB2 maybe, but when was the last time we heard
from anyone trying to migrate from DB2 to PG?)
Sourceforge?
They gave up on us years
; for instance
we'd not bother locking the rowtype of a relation when dropping the
relation. Can anyone think of a case where this would go wrong?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
.)
If there are no objections I'll apply this in a day or two.
regards, tom lane
binbughWDQ94c.bin
Description: dependency-1.patch.gz
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
compatibility. It's got quite enough on its plate
without people trying to convert it into an ETL tool.
Which is not to say that we don't need an ETL tool, just that it should
be separate from pg_dump.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql
. Then you don't
break compatibility for existing typanalyze functions. It's also less
code, since the standard typanalyze functions can rely on those preset
values.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
that there's not any real reason
to use pg_dump at all. Just do a COPY (SELECT ...) TO somefile.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
or
that a committer wants extra review of.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
?)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
could skip the if (!fail) tests occurring after calls to it.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
code to make it a bit
easier to deal with? My thought is probably not, and that seems
to be the majority opinion so far.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
then be simplified a bit by using this.
Not really. pg_dump has to support old server versions, so you won't
get any meaningful simplification by moving functionality out of pg_dump
into the backend; at least not before you've forgotten having made the
change :-(
regards, tom lane
it would make it more likely for people
to not notice the issue during testing.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
On the other hand, I remain unconvinced that this problem is severe
enough to justify much backporting work. AFAIK we've only seen one
occurence of a problem to date.
I know about two occurrence. One was reported on -bug
(http
as well.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
unconvinced that this problem is severe
enough to justify much backporting work. AFAIK we've only seen one
occurence of a problem to date.
Thoughts?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
) for ...?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Jeff Davis [EMAIL PROTECTED] writes:
On Tue, 2008-05-27 at 12:08 -0400, Tom Lane wrote:
How about ... converts an array of modifier(s) for ...?
Sounds good to me.
OK, done.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
from writing an infinite loop in plpgsql, either.
I think this patch is plenty complicated enough without adding useless
restrictive options.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
of comments in pg_config_manual.h seems
a more appropriate solution.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Tom Lane wrote:
Also, it seems a bit inconsistent to be relying on
oracle_compat.c for upper/lower but not initcap.
I saw this inconsistence while I'm doing the patch. What about moving
that upper/lower/initcap and wcs* code to another
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
One thing I did *not* like was changing the FSM API to refer to Relation
rather than RelFileNode --- I don't believe that's a good idea at all.
Oh really? I'm quite fond of the new API. From a philosophical point of
view
the
str_initcap routine respect current string conversion methods.
(str_initcap was outright wrong anyway since it assumed the output
must be the same byte length as the input.)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
of having any real use for them.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
care about one or the other.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
on
oracle_compat.c for upper/lower but not initcap.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
not. What I was imagining was that the resultcreate
callback would call PQresultSetInstanceData.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
Actually, I agree. Shall we just revert that feature?
Perhaps, but we should also take into account that TRUNCATE is not and
never will be MVCC compliant, so its not something you'd expect to run
except
anything.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
investigation, but blaming
the patch-at-hand for the issue is just misleading.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
like the above
all you need is a switch() and some pointer casts.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
have a couple more days to get it done.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
member names short, because you'll be typing
them a lot.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
Wait a minute --- you're trying to get between libpq and malloc?
Why? That's getting a *whole* lot more invasive than I thought
this patch intended to be, and I don't see a good reason for it.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
of the TRUNCATE part.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Merlin Moncure [EMAIL PROTECTED] writes:
On Fri, May 16, 2008 at 4:23 PM, Tom Lane [EMAIL PROTECTED] wrote:
So you're imagining that on creation of a PGconn or PGresult, the
hook function would be allowed to create some storage and libpq would
then be responsible for tracking that storage
warning and/or SSL info?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
as soon
as there's a version warning in there.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
function as
a key for retrieving the associated void * pointer. You'd need to
not register the same callback function more than once per object,
but from what I gather here you don't need to.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
It might work to use the address of the hook callback function as
a key for retrieving the associated void * pointer. You'd need to
not register the same callback function more than once per object,
but from what I gather here you
and destruction of PGconns and PGresults, you can maintain your
own index data structure. I'm willing to grant some amount of extra
API-stuff to save users having to do that in simple cases, but I don't
think we need to try to support infinitely complex cases.
regards, tom lane
any usage of that right now. I'll
add
this option.
Ping? I'd like to get this patch out of the way.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
in any case, because
that is what newbies are going to see.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
hook separately, eg
typedef void (*PGCRHook) (PGconn *conn, void *passthrough);
void PQregisterConnResetHook(PGconn *conn, PQCRHook func, void *passthrough);
... repeat for each possible hook ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
page (2323)
8-bit characters might not work correctly. See psql reference
page Notes for Windows users for details.
SSL connection (cipher: 2343, bits: 512)
Type help for help.
Why? Well, it's just more nearly the way it used to be.
regards, tom lane
. It didn't seem tremendously easy to fix though.
I suppose anyone who does have a problem can rewrite as
CASE x
WHEN a THEN ...
WHEN b THEN ...
WHEN c THEN ...
at the cost of duplicating their THEN code.
regards, tom lane
think you must have been out in the sun too long.
Hey, he's welcome to try to do it. But it's utterly unrelated to the
patch at hand, and we are not holding up the patch at hand until
something like that happens.
regards, tom lane
--
Sent via pgsql-patches mailing list
=# select 'supernova'::tsvector @@ 'super'::tsquery;
?column?
--
t
(1 row)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
just guessing about that.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
Where exactly is taht problem? In getrusage()? We have a getrusage() in
src/port that works fine on Windows, no?
Huh
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Shouldn't we at least make it fail with EINVAL if who doesn't match
whichever semantics this code is able to implement?
Yeah, we only ever call it asking for our own process, but I guess we
might at some point in the future change
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Martin Pihlak [EMAIL PROTECTED] writes:
Now I just realized that the current patch doesn't handle this quite
correctly. Modified patch attached.
Applied with revisions as per discussion.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
David Fetter [EMAIL PROTECTED] writes:
Surely this is merely proof of concept and not a complete patch.
Next patch attached :)
Uh, my point was that the agreement was to do this to *all* of psql's
toggling backslash commands, not only \timing.
regards, tom lane
using the same condition name, and I don't think it's
really important to make the user think about this.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
David Fetter [EMAIL PROTECTED] writes:
On Tue, May 13, 2008 at 11:36:57AM -0400, Tom Lane wrote:
Uh, my point was that the agreement was to do this to *all* of
psql's toggling backslash commands, not only \timing.
Done :)
Hmm, I thought we had a lot more than three that were like
if a strict function is skipped over because of NULL
arguments. I'm inclined to make it uniformly say that that's not a call
and is not included in the stats --- any objections?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
partial-match
operator.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
better than
child tables though :).
No, child tables sounds better to me. English doesn't usually
pluralize adjectives.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Also, I think that the whole snapshot-sharing mechanism is not working
as intended except for the serializable case; otherwise sequences
like
x = RegisterSnapshot(GetTransactionSnapshot());
y = RegisterSnapshot(GetTransactionSnapshot
plpgsql.out.rej
patching file plpgsql.sql
Hunk #1 FAILED at 2735.
1 out of 1 hunk FAILED -- saving rejects to file plpgsql.sql.rej
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Shouldn't UnregisterSnapshot insist that s_level be equal to current
xact nest level?
It can't check that; consider
begin;
savepoint foo;
declare cur cursor for select (1), (2), (3);
savepoint bar;
close cur;
commit;
Hmm
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm ... but that close can't unregister the snapshot immediately,
because you'd lose if the 2nd savepoint gets rolled back, no? Is the
handling of this case even correct at the moment?
No, CLOSE is not rolled back:
...
Maybe
of people will see
this particular aspect of it as a regression. I'm okay with
backpatching to 8.3 ... though the patch needed rather more testing
than you gave it.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
is stored into all the :scale variables at lines 1671-1691
(although not if you only have one client !?) only to be done over
again at lines 1746-1763 (though not if ttype != 3). Wasteful,
confusing, and there's a case where it fails to be done at all.
Sigh ...
regards, tom lane
here,
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
warranted, samples:
Actually that didn't work, because scale defaults to 1, so it would
*always* warn ... I applied the attached instead.
regards, tom lane
Index: pgbench.c
===
RCS file: /cvsroot/pgsql/contrib/pgbench
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, 8.3 is already different from 8.2, and a lot of people will see
this particular aspect of it as a regression. I'm okay with
backpatching to 8.3 ... though the patch needed rather more testing
than you gave it.
OK, so Alvaro
implications. In the back branches,
ADD CHECK followed by DROP CONSTRAINT will end up not deleting the
child-table constraints, which is probably a bug but I wouldn't be
surprised if applications were depending on the behavior.
regards, tom lane
--
Sent via pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
seven times out of eight
this assumption is wrong.
An actually acceptable solution would involve emitting the correct
number of spaces depending on how much we've put out so far.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
Bruce Momjian [EMAIL PROTECTED] writes:
I have developed the attached patch which fixes 0 ^ 123.3.
Did you actually read the wikipedia entry you cited?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
before
decrementing, likewise in UnregisterSnapshot.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
I wrote:
Also, I don't think the subtransaction management is correct at all.
BTW, maybe it would make more sense to keep the reference count
management inside ResourceOwners, instead of having a largely
duplicative set of logic in snapmgr.c.
regards, tom lane
--
Sent
from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
I'm willing to take it up and work on it.
Excellent! As you say, you've
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
I think the use-case for varying the WAL segment size is unrelated to
performance of the master server, but would instead be concerned with
adjusting the granularity of WAL log shipping.
Seems
changes were just plain broken, eg several places in selfuncs.c where
you allowed strlen() to be applied to a bytea converted to cstring.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
attempted load.
I also improved the documentation a bit and added the copy step needed
in restore_backend_variables().
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Andrew Dunstan [EMAIL PROTECTED] writes:
I notice that this patch adds an Elements column to the output of \dT,
which will only be used by enum types. That seems rather ... cluttered.
But it'll only be in \dT+ anyway, no?
regards, tom lane
--
Sent via pgsql-patches
use one that
the unused_oids script reports as free.
There was no check for a zero step size.
There was no documentation.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
Greg Smith [EMAIL PROTECTED] writes:
On Sun, 4 May 2008, Tom Lane wrote:
However, I am completely unable to measure any performance improvement
from it. Given the possible risk of out-of-memory failures, I think the
patch should not be applied without some direct proof of performance
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
But it'll only be in \dT+ anyway, no?
Not in this patch.
Hmmm ... given that a long list of enum members would bloat the output
quite a lot, I think I'd vote for putting it in \dT+.
regards, tom lane
--
Sent
,
( ...,
have_sqlstate ? errcode(...) : 0,
...
That is, you should evaluate all the options into local variables
and then do one normal ereport call.
* // comments are against our coding conventions.
regards, tom lane
--
Sent via pgsql
Greg Smith [EMAIL PROTECTED] writes:
On Sun, 4 May 2008, Tom Lane wrote:
Well, I tried a pgbench test similar to that one --- on smaller hardware
than was reported, so it was a bit smaller test case, but it should have
given similar results.
... If
you're not offloading to another device
/wholly reserved
words. So maybe a boolean would be sufficient --- but I have nothing
against the R/T/C/U suggestion.
A more radical alternative is just to omit unreserved words from the
view altogether.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql
the granularity of WAL log shipping.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
pg_config.h.win32 that Tom raised first.
+1 for both. We really need to eliminate as much redundancy as we can
between the two build systems, because it'll keep biting us until we do.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
--- which might only be
the handler function, though you could make a case for the validator and
the trusted flag as well.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
those externs in
keywords.h instead. I suspect you have ignored a compiler warning
about not declaring pg_get_keywords itself, too --- it should be
extern'd in builtins.h.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
brains anymore. (Besides, some of us
remember it as octal 12, anyway...)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /cvsroot/pgsql/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.228
diff -c -r1.228 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 1 Jan 2008 19:45
to be separately configurable?
I could see having the same configure switch set both of 'em.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
admittedly you could argue that they could all use a ton more
documentation than they now have, but it's not reasonable to insist
on just this one meeting a different standard.)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
101 - 200 of 3477 matches
Mail list logo
