On 2023-06-08 14:01:16 +0200, Jose Luis Tallon wrote:
> * For "heavyweight" queries, the scalability of "almost independent"
> processes w.r.t. NUMA is just _impossible to achieve_ (locality of
> reference!) with a pure threaded system. When CPU+mem-bound
> (bandwidth-wise), threads add nothing
On 2023-06-08 10:33:26 -0400, Greg Stark wrote:
> On Wed, 7 Jun 2023 at 18:09, Andres Freund wrote:
> > Having the same memory mapping between threads makes allows the
> > hardware to share the TLB (on x86 via process context identifiers), which
> > isn't realistically po
sing camelcase parameters? This part of the change
just blows up the size, making it harder to review.
12 files changed, 317 insertions(+), 297 deletions(-)
...
Greetings,
Andres Freund
DING', 'exe'
> + ]
> +
> + rcgen_bin_args = rcgen_server_args + [
> '--ICO', pg_ico
>]
Somehow it seems a bit wrong to derive non-server from server, but ... ;)
Greetings,
Andres Freund
.63s on my machine. Without it I
lost patience after 2 minutes. And the test was only at the start (8 out of 78
subtests).
Greetings,
Andres Freund
ut threading support - which would allow us
to get rid of a very significant amount of code and runtime overhead.
Greetings,
Andres Freund
egister. Whereas each
individual variable being in TLS makes the job harder for the compiler.
Greetings,
Andres Freund
Hi,
On 2023-06-07 23:39:01 +0200, Peter Eisentraut wrote:
> On 07.06.23 23:30, Andres Freund wrote:
> > Yea, we definitely need the supervisor function in a separate
> > process. Presumably that means we need to split off some of the postmaster
> > responsibilities - e.g. I
ess state is shared. But
that's by far outweighed by most debugging / validation tools not
understanding the multi-processes-with-shared-shmem model.
Greetings,
Andres Freund
here's plenty of things we can do before, but in the end I think tackling the
issues you mention and moving to threads are quite tightly linked.
Greetings,
Andres Freund
up being beneficial even in the process world.
A related issue is that we won't get SIGCHLD in the supervisor process
anymore. So we'd need to come up with some design for that.
Greetings,
Andres Freund
ssue. It seems quite possible
we're going to hit such issues in other places.
Greetings,
Andres Freund
bool alloc_bistate, bool is_multi)
Why have alloc_bistate and options?
> +static inline void
> +table_insert_end(TableInsertState *state)
> +{
> + /* Deallocate bulk insert state here, since it's AM independent. */
> + if (state->bistate)
> + FreeBulkInsertState(state->bistate);
> +
> + state->rel->rd_tableam->tuple_insert_end(state);
> +}
Seems like the order in here should be swapped?
Greetings,
Andres Freund
king of generating a
depfile from within perl. Something like what you propose doesn't quite seems
like a sufficient improvement.
> Otherwise, manual as it is in the original patch seems like an alright
> compromise for now.
Yea. I'm working on a more complete version, also dealing with
erl output the files it loads and
handle dependencies automatically that way? But that's more work, so it's
probably the right thing to go for the manual path for now.
Greetings,
Andres Freund
um in verbose mode (as suggested by Shi-san) and
> depending of its output run the "invalidation" test or: re-launch the vacuum,
> re-check the output
> and so on.. (n times max). If n is reached, then skip this test.
I think the best fix would be to wait for a new snapshot that has a newer
horizon, before doing the vacuum full.
Greetings,
Andres Freund
Hi,
On 2023-05-26 09:02:33 +0200, Peter Eisentraut wrote:
> On 24.05.23 23:24, Andres Freund wrote:
> > First thing I noticed that 'make dist' doesn't work in a vpath, failing in a
> > somewhat obscure way (likely because in a vpath build the the copy from the
> > sourc
Hi,
On 2023-05-25 13:05:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-05-25 09:09:45 -0400, Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> Why does pgindent require that pg_bsd_indent be installed in the path?
>
> > Isn't the situ
_bt_getbuf(). We probably should evolve the design in the area, and
that will be easier with such a change.
Greetings,
Andres Freund
n't do that, because the
autoconf vpath build copies such directories, which isn't fun).
Greetings,
Andres Freund
ing of
> data using [`COPY`](https://www.postgresql.org/docs/16/sql-copy.html) up to
> a 300%.
It also speeds up concurrent loading when not using COPY, just to a lesser
degree. But I can't come up with a concise phrasing for that right now...
Greetings,
Andres Freund
rts 64 bit atomics these days, via LLWP /
SCWP.
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-6.06.pdf
documents them as having been added to MIPS32 Release 6, from 2014.
Greetings,
Andres Freund
Hi,
On 2023-05-24 19:51:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> >> Hmm, can we really expect atomic 8-byte reads on "relevant" 32-bit
> >> platforms? I'd be on board with this if so
Hi,
On 2023-05-24 19:57:39 -0400, Jonathan S. Katz wrote:
> On 5/24/23 5:28 PM, Andres Freund wrote:
> >
> > I think the relation extension improvements ought to be mentioned here as
> > well? Up to 3x faster concurrent data load with COPY seems practically
>
Hi,
On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Dropping CPUs without native atomic operations / without a way to do
> > tear-free
> > 8 byte reads would make several substantial performance improvements easier,
> > while not really dro
in isolation.
> That's not a reason to reject it, though, just something that makes me
> curious.
I doubt it's a meaningful, if even measurable win. But removing atomic ops and
reducing shared memory space isn't a bad thing, even if there's no immediate
benefit...
Greetings,
Andres Freund
bstantial performance improvements easier,
while not really dropping any relevant platform.
Etc.
Greetings,
Andres Freund
ushed. So a backend with such a spurious SyncRepWaitForLSN()
would just wait until the LSN is actually flushed and *then* replicated.
Any specific reason for that question?
Greetings,
Andres Freund
Q-CONNECT-LOAD-BALANCE-HOSTS)
> to libpq, the client library for PostgreSQL.
I think the relation extension improvements ought to be mentioned here as
well? Up to 3x faster concurrent data load with COPY seems practically
relevant.
Greetings,
Andres Freund
Hi,
On 2023-05-23 14:51:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I guess I need to go and check how long the "release" tarball generation
> > takes...
>
> It's quick except for the documentation-generating steps. Maybe
> we could test that part
Hi,
On 2023-05-24 05:53:51 +, Zhijie Hou (Fujitsu) wrote:
> On Tuesday, May 23, 2023 1:53 AM Andres Freund wrote:
> > On 2023-05-22 12:15:07 +, Zhijie Hou (Fujitsu) wrote:
> > > About "a backend doing logical decoding", do you mean the case when a
&g
nt, and
> >> more in line with how we do things. But it's not clear to me why we'd
> >> end up with the same problem in a few years with what the patch does.
> >
> > Because it sets up the pattern of manual memory management and continues to
> > run the releva
oing the work in ExecGetAllUpdatedCols()
over and over? Unless I am missing something, the result doesn't change
across rows. And it doesn't look that cheap to compute, leaving aside the
allocation that bms_union() does.
It's visible in profiles, not as a top entry, but still.
Perhaps the easiest to backpatch fix is to just avoid recomputing the value?
But perhaps it'd be just as problmeatic, because callers might modify
ExecGetAllUpdatedCols()'s return value in place...
Greetings,
Andres Freund
dCols(rootrel, estate),
ExecGetUpdatedCols(rootrel, estate));
}
Once in ExecPartitionCheckEmitError(), *twice* in ExecConstraints(),
ExecWithCheckOptions(). Some of the partitioning stuff has been added in a
really myopic way.
Greetings,
Andres Freund
oncern. I think it might be reasonable to use something
like ExecGetAllUpdatedColsCtx() in the backbranches, and switch to a
short-lived context for the trigger invocations in >= 16.
Greetings,
Andres Freund
Hi,
On 2023-05-23 23:26:42 +0200, Tomas Vondra wrote:
> On 5/23/23 19:14, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-23 18:23:00 +0200, Tomas Vondra wrote:
> >> This means that for an UPDATE with triggers, we may end up calling this
> >> for each ro
Hi,
On 2023-05-24 10:56:28 +0900, Kyotaro Horiguchi wrote:
> At Wed, 26 Apr 2023 11:37:55 +1200, Thomas Munro
> wrote in
> > On Tue, Apr 25, 2023 at 12:16 PM Andres Freund wrote:
> > > On 2023-04-24 15:32:25 -0700, Andres Freund wrote:
> > > >
d in the patch use optarg, opterr etc. - which are declared in
pg_getopt.h. Making it reasonable to directly include pg_getopt.h.
I don't really see a need to change anything here?
Greetings,
Andres Freund
ed to go and check how long the "release" tarball generation
takes...
Greetings,
Andres Freund
Hi,
On 2023-05-23 13:28:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Could it help to have a mode where the executor shutdown hook checks how
> > much
> > memory is allocated in ExecutorState and warns if its too much?
>
> It'd be very hard to set a limit f
ise we'll just end up with the same
problem in a few years.
Greetings,
Andres Freund
Hi,
On 2023-05-21 22:52:09 -0400, Bruce Momjian wrote:
> On Sun, May 21, 2023 at 10:13:41AM -0700, Andres Freund wrote:
> > Hi,
> >
> > Thanks for the release notes!
> >
> > >
> > >
> > >
> > >
> > > Allow more e
this item as a big win, but I don't know how to describe it in a way
> that is helpful for the user to know.
In doubt the subject of the commit would just work IMO.
Greetings,
Andres Freund
ot the details, but IIRC there's some outfuncs
(enum?) that intentionally delay releasing locks till transaction commit.
Greetings,
Andres Freund
lso not accessible, so that's not a problem.
It's not the prettiest solution, but I think the simplicity is worth a lot.
Greetings,
Andres Freund
Hi,
On May 21, 2023 11:46:56 AM PDT, "Jonathan S. Katz"
wrote:
>On 5/21/23 1:13 PM, Andres Freund wrote:
>
>>
>> Looking through the release notes, I didn't see an entry for
>>
>> commit c6e0fe1f2a08505544c410f613839664eea9eb21
>> Author: Davi
Hi,
Thanks for the release notes!
>
>
>
>
> Allow more efficient addition of multiple heap and index pages (Andres Freund)
>
>
While the case of extending by multiple pages improved the most, even
extending by a single page at a time got a good bit more scalable
so did some minor
comment polishing.
Greetings,
Andres Freund
oing logical decoding - which
can't progress until the startup process wakes the backend up.
So I don't think this is promising avenue in the near term.
Greetings,
Andres Freund
od
> news. My testing scripts have been improved so I should be able to finish
> the next round of tests in less time.
With "yet to see any significant changes" do you mean that the runs are
comparable with earlier runs, showing the same regression? Or that the
regression vanished? Or ...?
Greetings,
Andres Freund
Hi,
On 2023-05-18 17:03:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > What about an interval / interval -> double operator that errors out
> > whenever
> > month is non-zero? As far as I can tell that would always be deterministic.
>
> We have
for IO).
What about an interval / interval -> double operator that errors out whenever
month is non-zero? As far as I can tell that would always be deterministic.
Greetings,
Andres Freund
On 2023-05-17 09:22:19 -0400, Robert Haas wrote:
> Adding pgstat_get_wait_extension adds runtime cost for no corresponding
> benefit. Having a special case in the code to avoid that seems worthwhile.
I don't think that should ever be used in a path where performance is
relevant?
Hi,
On May 17, 2023 2:51:41 PM PDT, Andrew Dunstan wrote:
>
>On 2023-05-16 Tu 17:52, Andres Freund wrote:
>>
>>> I suppose the alternative would be to change the way the buildfarm calls
>>> pg_ctl stop. Do you have a concrete suggestion for that?
>> The easi
Hi,
On 2023-05-17 12:53:15 -0700, Andres Freund wrote:
> I'll try to come up with a benchmark without the issues I pointed out in
> https://postgr.es/m/20230517194331.ficfy5brpfq5lrmz%40awork3.anarazel.de
Here we go:
setup:
create primary
SELECT pg_create_physical_replication_slot('r
entSetWait() can be replaced with its CV's
> + * counterpart.
I don't really understand that XXX - the potential bright future would be to
add support for CVs into wait event sets, not to replace WES with a CV?
Greetings,
Andres Freund
quot;original" cost of the function.
gprof style instrumentation is good for things like code coverage, but for
performance evaluation it's normally better to use a sampling profiler like
perf. That also causes slowdowns, but largely only in places that already take
up substantial execution time.
Greetings,
Andres Freund
Hi,
On 2023-05-10 08:39:08 +0200, Drouvot, Bertrand wrote:
> On 5/9/23 11:00 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> > > On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > > > I don't
unds like it's pretty close to being ready.
Thanks for the nudge. I just pushed the changes, with some very minor changes
(a newline, slight changes in commit messages).
I'll go and mark the item as closed.
Greetings,
Andres Freund
Hi,
On 2023-05-16 20:40:01 +0200, Peter Eisentraut wrote:
> On 10.05.23 20:10, Andres Freund wrote:
> > > So if you want to understand what smgrzeroextend() does, you need to
> > > mentally combine the documentation of three different functions. Could we
> > >
Hi,
On 2023-05-17 08:41:24 +1200, Thomas Munro wrote:
> Yeah. No one seems to think this is worth worrying about (please
> speak up if you do).
+1 - we have much bigger fish to fry IMO.
Greetings,
Andres Freund
; I suppose the alternative would be to change the way the buildfarm calls
> pg_ctl stop. Do you have a concrete suggestion for that?
The easiest fix is to redirect stdin to /dev/null (or some file, if that's
easier to do portably) - that should fix the problem entirely, without needing
IPC::Run.
Greetings,
Andres Freund
Hi,
On 2023-05-16 09:38:54 +0900, Michael Paquier wrote:
> On Mon, May 15, 2023 at 05:17:16PM -0700, Andres Freund wrote:
> > IMO the submission should include why automating requires these changes
> > (yours
> > doesn't really either). I can probably figure it
r
performance when forcing things to be colocated.
Greetings,
Andres Freund
Hi,
On 2023-05-16 07:30:54 +0900, Michael Paquier wrote:
> On Mon, May 15, 2023 at 11:29:56AM -0700, Andres Freund wrote:
> > Without an explanation for why this change is needed for [1], it's hard to
> > give useful feedback...
>
> The point is to integrate the wait event c
Hi,
On 2023-05-15 14:20:24 +0900, Michael Paquier wrote:
> On Thu, May 11, 2023 at 01:28:40PM +0900, Michael Paquier wrote:
> > On Tue, May 09, 2023 at 09:48:24AM -0700, Andres Freund wrote:
> >> On 2023-05-08 12:11:17 -0700, Andres Freund wrote:
> >>> I can reproduc
Hi,
On 2023-05-15 15:30:28 -0700, Andres Freund wrote:
> As soon as either the pg_ctl for the start, or the whole bash invocation, has
> stdin redirected, the problem vanishes.
For a moment I thought this could be related to InheritStdHandles() - but no,
it doesn't make a difference.
T
Hi,
On 2023-05-15 13:13:26 -0700, Andres Freund wrote:
> It wouldn't really - the echo $? inside the system() would report the
> error. Which it doesn't - note the "0" in the second output.
Ah. Interesting. Part of the issue is perl (or msys?) swalling some error
details.
Hi,
On 2023-05-15 16:01:39 -0400, Andrew Dunstan wrote:
> On 2023-05-15 Mo 15:38, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> > > If you want to play I can arrange access.
> > Andrew did - thanks!
> >
>
uff that InheritstdHandles()
does?
Andrew, is it ok if modify pg_ctl.c and rebuild? I don't know how "detached"
from the actual buildfarm animal the system you gave me access to is...
Greetings,
Andres Freund
ww.postgresql.org/message-id/flat/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9...@gmail.com
>
> Looking forward to your feedback,
Without an explanation for why this change is needed for [1], it's hard to
give useful feedback...
Greetings,
Andres Freund
Hi,
On May 12, 2023 11:36:23 AM PDT, Thomas Munro wrote:
>Just a thought: should RelationCopyStorageUsingBuffer(), the new code
>used by CREATE DATABASE with the default strategy WAL_LOG, use the
>newer interface so that it creates fully allocated files instead of
>sparse ones?
I played with
Hi,
On May 11, 2023 2:37:00 AM PDT, Peter Eisentraut
wrote:
>On 10.05.23 20:10, Andres Freund wrote:
>>> Moreover, the text "except the relation can be extended by multiple blocks
>>> at once and the added blocks will be filled with zeroes" doesn't make much
ust does it by writing data.
The FileFallocate() path in smgrzeroextend() tries to avoid writing data if
extending by sufficient blocks - not having dirty data in the kernel page
cache can substantially reduce the IO usage.
Whereas the FileZero() path just optimizes the number of syscalls (and cache
misses etc).
Greetings,
Andres Freund
Hi,
On 2023-05-10 17:44:07 +0200, Peter Eisentraut wrote:
> On 12.03.23 00:41, Andres Freund wrote:
> > Hi,
> >
> > On 2023-03-11 15:34:55 -0800, Mark Dilger wrote:
> > > > On Mar 11, 2023, at 3:22 PM, Andres Freund wrote:
> > > >
> > &
Hi,
On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > I don't think the approach of not having any sort of "registry" of
> > whether
> > anybody is waiting for the replay position to be updated is
&
he reason why the context matters is that some reloptions are disallowed to
> change after creating
> the table, while some reloptions are allowed.
What kind of reloption are you thinking of here?
Greetings,
Andres Freund
Hi,
Unfortunately I have found the following commit to have caused a performance
regression:
commit e101dfac3a53c20bfbf1ca85d30a368c2954facf
Author: Andres Freund
Date: 2023-04-08 00:24:24 -0700
For cascading replication, wake physical and logical walsenders separately
Physical
Hi,
On 2023-05-08 12:11:17 -0700, Andres Freund wrote:
> Hi,
>
> On 2023-05-08 16:00:01 +0300, Alexander Lakhin wrote:
> > This difference is confirmed by multiple test runs. `git bisect` for this
> > regression pointed at f193883fc.
>
> I can reproduce a significant
if 'invalid because creating' and
> 'invalid because dropping' were distinguished).
I'm bit hesitant to do so for now. Once it's a bit more settled, maybe?
Although I wonder if there's something better suited to the task than
autovacuum.
Greetings,
Andres Freund
and at segment
> boundaries.
I've pondered that as well. But I don't think it's great - it's not exactly
intuitive that stats reporting gets far less common if you use a 1GB
wal_segment_size.
Greetings,
Andres Freund
Hi,
On 2023-04-25 10:28:58 -0700, Andres Freund wrote:
> On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> > On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > > What we've discussed somewhere in the past is to always truncate N+1 when
> > > creating the first p
; SEGSIZE it'll
only truncate , not .N. And boom, a disconnected
segment.
(I'll post a separate email about an evolved proposal about fixing this set of
issues)
Greetings,
Andres Freund
Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> On 2023-05-04 Th 19:54, Andres Freund wrote:
> > Hm. I can't reproduce this in my test win10 VM, unfortunately. What OS / OS
> > version is the host? Any chance to get systeminfo.exe output or something
> > like
but haven't we gone further and even
backpatched things like spinlock support for new arches in the past?
Greetings,
Andres Freund
ed. We also now need to do permission checking etc.
I don't think that's the entirety of the regression...
Greetings,
Andres Freund
e low, but 16
has two low results.
Greetings,
Andres Freund
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
> > > buildfarm support fo
l use the normal backend logic, and thus also trigger writebacks?
Greetings,
Andres Freund
uldn't be too
hard. I'll try to look more tomorrow.
Greetings,
Andres Freund
context to ScheduleBufferTagForWriteback instead?
> --- a/src/test/regress/sql/stats.sql
> +++ b/src/test/regress/sql/stats.sql
Hm. Could we add a test for this? While it's not implemented everywhere, we
still issue the smgrwriteback() afaics. The default for the _flush_after GUCs
changes, but backend_flush_after is USERSET, so we could just change it for a
single command.
Greetings,
Andres Freund
lso what are the 'seconds' and 'tbl-MBs' metrics that were reported.
The total time for inserting N (1024 for the small files, 64 for the larger
ones). "tbl-MBs" is size of the resulting table, divided by time. I.e. a
measure of throughput.
Greetings,
Andres Freund
;
> [2] COPY (SELECT repeat(random()::text, 5) FROM generate_series(1, 6*10))
> TO '/tmp/copytest_data_text.copy' WITH (FORMAT text);
Greetings,
Andres Freund
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > Hi,
> >
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
>
s dependent on the windows runtime
version.
Downthread you mention that the issue doesn't happen with IPC::Run - the
biggest difference I can see is that IPC::Run would IIRC not use a shell? Does
the problem "re-appear" if you make IPC::Run use a shell?
Greetings,
Andres Freund
nclude/utils/timeout.h b/src/include/utils/timeout.h
> index e561a1cde9..a8d360e255 100644
> --- a/src/include/utils/timeout.h
> +++ b/src/include/utils/timeout.h
> @@ -35,6 +35,7 @@ typedef enum TimeoutId
> IDLE_STATS_UPDATE_TIMEOUT,
> CLIENT_CONNECTION_CHECK_TIMEOUT,
> STARTUP_PROGRESS_TIMEOUT,
> + STARTUP_STAT_FLUSH_TIMEOUT,
> /* First user-definable timeout reason */
> USER_TIMEOUT,
> /* Maximum number of timeout reasons */
I think we could just reuse IDLE_STATS_UPDATE_TIMEOUT?
Greetings,
Andres Freund
Hi,
On 2023-04-25 16:00:24 -0400, Robert Haas wrote:
> On Tue, Apr 25, 2023 at 2:39 PM Andres Freund wrote:
> > I'm mildly inclined to not consider it a bug, given that this looks to have
> > been true for other stats for quite a while? But it does still seem worth
> > impr
tup process on the standby.
> Elsewhere on the internet where you originally raised this, I mentioned
> that I hacked a pgstat_flush_io() into the redo apply loop in
> PerformWalRecovery() but that I wasn't sure that this was affordable.
> Andres Freund replied saying that it would be too
Hi,
On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> On Mon, Apr 24, 2023 at 8:03 PM Andres Freund wrote:
> > What we've discussed somewhere in the past is to always truncate N+1 when
> > creating the first page in N. I.e. if we extend into 23456.1, we truncate
> > 23456.2
Hi,
On 2023-04-24 15:32:25 -0700, Andres Freund wrote:
> On 2023-04-24 10:53:35 +0200, Christoph Berg wrote:
> > I'm often seeing PG16 builds erroring out in the pgbench tests:
> > I don't think the disk is full since it's always hitting that same
> > spot, on some of
901 - 1000 of 8831 matches
Mail list logo
