On Wed, 2021-09-01 at 10:33 +0900, Michael Paquier wrote:
> On Tue, Aug 31, 2021 at 04:55:35AM +0200, Laurenz Albe wrote:
> > In the view of that, how about doubling PGSTAT_STAT_INTERVAL to 1000
> > milliseconds?
>
> Perhaps we could do that. Now, increasing an int
On Tue, 2021-08-31 at 21:16 -0700, Andres Freund wrote:
> On 2021-09-01 05:39:14 +0200, Laurenz Albe wrote:
> > On Tue, 2021-08-31 at 18:55 -0700, Andres Freund wrote:
> > > > > On Tue, Aug 31, 2021 at 04:55:35AM +0200, Laurenz Albe wrote:In the
> > > >
On Wed, 2021-09-01 at 10:56 +0200, Laurenz Albe wrote:
> On Tue, 2021-08-31 at 21:16 -0700, Andres Freund wrote:
> > On 2021-09-01 05:39:14 +0200, Laurenz Albe wrote:
> > > On Tue, 2021-08-31 at 18:55 -0700, Andres Freund wrote:
> > > > > > On Tue, Aug 31, 20
On Fri, 2021-09-03 at 18:24 +0200, Daniel Gustafsson wrote:
> > On 6 Apr 2021, at 09:46, Amit Langote wrote:
> > On Fri, Apr 2, 2021 at 11:36 PM Laurenz Albe
> > wrote:
>
> > > I don't know if Seamus is still working on that; if not, we might
>
; didn't do the same for disconnecting, but perhaps that would be better? Then
> we could get rid of the whole pgStatSessionEndCause variable.
I see your point, but I am not certain if it is worth adding yet another message
for a small thing like that. I have no strong opinion on that though.
Reading your patch, I am still confused about the following:
There are potentially several calls to "pgstat_send_tabstat" in
"pgstat_report_stat".
It seems to me that if it were called more than once, session statistics would
be reported and counted several times, which would be wrong.
Yours,
Laurenz Albe
On Mon, 2021-09-06 at 00:22 -0700, Andres Freund wrote:
> On 2021-09-06 09:12:58 +0200, Laurenz Albe wrote:
> > Reading your patch, I am still confused about the following:
> > There are potentially several calls to "pgstat_send_tabstat" in
> > "pgstat_report_
noying and would
welcome the change. This has bothered me before.
That multi-line statements that contain a line with a space are omitted
from the history when HISTCONTROL is set to "ignorespace" seems like
a bug to me.
So +1 on the idea of the patch, although I didn't scrutinize the
implementation.
Yours,
Laurenz Albe
n a static variable pgLastSessionReportTime
- add a comment to explain why we only track normal backends
- pgindent
- an attempt at a commit message
Yours,
Laurenz Albe
From 1fdfac528ec4e75d91b9cf3868eda66a72a41c8f Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 8 Sep 2021 06:06:46 +0200
Subje
onnection pool,
would skew the statistics.
Yours,
Laurenz Albe
On Thu, 2021-09-30 at 18:26 -0400, Chapman Flack wrote:
> On 09/30/21 17:54, Florin Irion wrote:
> > We could also help users get a warning if they set a parameter with the
> > `SET` command.
>
> So I am in favor of patching this.
+1 on the idea.
Yours,
Laurenz Albe
to the next commit fest?
Thanks for that work; help with Windows is always welcome.
Please go ahead and add the patch to the commitfest yourself.
Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.
Yours,
Laurenz Albe
tected.
What about adding an Assert that gags on NULLs, but still printing them
as "(null)"? That would help find such problems in a debug build.
Yours,
Laurenz Albe
unting purposes, though.
But I don't expect it to be in frequent enough demand to add a psql command.
What about inventing a function pg_schema_size(regnamespace)?
Yours,
Laurenz Albe
ormation Functions"
> seems the most logical place to put these.
>
> [1] https://www.postgresql.org/docs/current/catalog-pg-database.html
> [2]
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b
>
> Will add to the next commitfest.
+1
Yours,
Laurenz Albe
e is certainly a minor inconvenience.
But I don't buy your second point: if it is like that, why do we have
Asserts at all?
Yours,
Laurenz Albe
On Thu, 2021-07-15 at 20:16 -0500, Justin Pryzby wrote:
> On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> > Besides, schemas are not physical, but logical containers. So I see a
> > point in
> > measuring the storage used in a certain tablespace, b
g that saps more performance or is complicated would not
be worth the effort.
Yours,
Laurenz Albe
. But I admit is is not frequently used.
In a data warehouse, which is updated only occasionally, running
CLUSTER after an update can make a lot of sense.
I personally think that it is enough to be able to cluster the table
partiton by partition.
Yours,
Laurenz Albe
ause the
cancel request succeeded) will later turn out to be committed after all,
just like it is now (only later). Where is the advantage?
Besides, there is no room for another transaction status in the
commit log.
Yours,
Laurenz Albe
questionable.
> That'd likely be more change than what we would want to do at this point in
> the release cycle though. But I think we ought to do something about the
> increased overhead...
If you are talking about the extra GetCurrentTimestamp() call, and my first
suggestion is acceptable, that should be simple.
Yours,
Laurenz Albe
sure if it is useful enough to break the standard in a way that may be
incompatible with future extensions of the standard.
Yours,
Laurenz Albe
On Tue, 2021-08-17 at 02:14 -0700, Andres Freund wrote:
> On 2021-08-17 10:44:51 +0200, Laurenz Albe wrote:
> > On Sun, 2021-08-01 at 13:55 -0700, Andres Freund wrote:
> > > We maintain last_report as GetCurrentTransactionStopTimestamp(), but then
> > > use
&g
oding different from the database encoding.
So I am not too excited about this.
> +1 once that Oracle Database 12.2 and higher, has support for 128 bytes names.
> What possibly, in the future, could impact some migration from Oracle to
> Postgres.
That seems to be a better argument from my point of view.
I have no idea as to how bad the additional memory impact for the catalog
caches would be...
Yours,
Laurenz Albe
On Tue, 2021-08-24 at 15:12 +0900, Kyotaro Horiguchi wrote:
> At Wed, 18 Aug 2021 05:16:38 +0200, Laurenz Albe
> wrote in
> > On Tue, 2021-08-17 at 02:14 -0700, Andres Freund wrote:
> > > > > I'm also not all that happy with sending yet anothe
g reason to keep it in the PostgreSQL source tree?
With PostgreSQL's extensibility features, it should be possible to write your
job scheduler as an extension and maintain it outside the PostgreSQL source.
I am sure that the PostgreSQL community will be happy to use the extension
if it is any good.
Yours,
Laurenz Albe
changes were trimmed only in the below file
> modified: configure
> modified: configure.ac
Did you forget an attachment?
Yours,
Laurenz Albe
haven't looked at in depth. Whichever direction
> we go, I think it's worth updating the documentation to make the
> behavior around triggers and roles clear.
I agree: adding a sentence somewhere won't hurt.
I'll do that once the feedback has given me the feeling that I am on
the right track.
Yours,
Laurenz Albe
ng
with %.*s in fprintf(), or we could make the "sqlstate" one byte longer.
I think that the second option would be less error-prone.
Yours,
Laurenz Albe
is is indeed buggy and need to take the length into account, as per the
> attached. This only happens when in the undocumented regression test debug
> mode which may be why it's gone unnoticed.
So you think we should ignore that compiler warning?
What about using memcpy() instead of strncpy()?
Yours,
Laurenz Albe
On Fri, 2024-06-14 at 10:10 +0200, Daniel Gustafsson wrote:
> > On 14 Jun 2024, at 10:06, Laurenz Albe wrote:
>
> > So you think we should ignore that compiler warning?
>
> We already do using this in meson.build:
>
> # Similarly disable useless truncation warni
y distracting from serious
problems and fill up the disk.
But you are probably right that it would be hard to find a default setting
that nobody has quibbles with, and the default can always be changed with
a future patch.
Yours,
Laurenz Albe
From 8e1eeb9cbcb94d9b15eb9ee97956cc4044ff7964 Mon Sep 1
ined.
For example, what is '1 year' / '1 day'?
- 365.24217, because that is the number of solar days in a solar year?
- 365, because we don't consider leap years?
- 360, because we use the usual conversion of 1 month -> 30 days?
Yours,
Laurenz Albe
nformation should go somewhere here:
https://www.postgresql.org/support/versioning/
Yours,
Laurenz Albe
e it as it is?
Concerning the latter, I am hoping for a detailed description of our
customer's use case some time soon.
Yours,
Laurenz Albe
t this point.
Nice.
I think we can safely rule out option 3.
Even if it is a bug, it is not one that has bothered anybody so far that a
backpatch
is indicated.
Yours,
Laurenz Albe
ng as designed, but if it is, I think it
should be documented.
Yours,
Laurenz Albe
On Sat, 2024-06-22 at 17:50 -0400, Joseph Koshakow wrote:
> On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe wrote:
> > Like you, I was surprised by the current behavior. There is a design
> > principle that PostgreSQL tries to follow, called the "Principle of
> > least ast
dback.
Based on that, the patch should be rejected.
Since there were a couple of other opinions early in the thread, I'll let
it sit like that for now, and judgement can be passed at the end of the
commitfest. Perhaps somebody else wants to chime in.
Yours,
Laurenz Albe
racy of the collation sort order and other locale aspects.
But they care a lot about index corruption.
So I'd argue that we should not have any breaking changes at all, even in
cases where the provider is clearly wrong.
Yours,
Laurenz Albe
ion to users.
> See V5, thanks for the wording ;)
Why not just leave it at plain "done"?
After all, the server was started successfully.
The second message should make sufficiently clear that the server has stopped.
I didn't like the code duplication introduced by the patch, so I rewr
\ev or \ef, right?
Yours,
Laurenz Albe
But this was reverted in 2535c74b1a6190cc42e13f6b6b55d94bff4b7dd6.
Yours,
Laurenz Albe
uming */
boolvacuum_truncate;/* enables vacuum to truncate a relation */
+ int max_local_update; /* Updates to pages after this block must
go through the VM */
} StdRdOptions;
#define HEAP_MIN_FILLFACTOR10
In the comment, it should be FSM, not VM, right?
Other than that, I see nothing wrong.
Yours,
Laurenz Albe
On Sat, 2023-07-08 at 08:11 +0200, Kim Johan Andersson wrote:
> On 07-07-2023 13:20, Laurenz Albe wrote:
> > I wrote:
> > > You implement both "SupportRequestIndexCondition" and
> > > "SupportRequestSimplify",
> > > but when I e
On Thu, 2023-08-17 at 09:37 +0900, Michael Paquier wrote:
> I have just noticed that we do not have a CF entry for this proposal,
> so I have added one with Laurenz as author:
> https://commitfest.postgresql.org/44/4504/
I have changed the author to Fujii Masao.
Yours,
Laurenz Albe
On Thu, 2023-08-24 at 18:23 +0200, Matthias van de Meent wrote:
> On Wed, 19 Jul 2023 at 15:13, Thom Brown wrote:
> >
> > On Wed, 19 Jul 2023, 13:58 Laurenz Albe, wrote:
> > > I agree that the name "max_local_update" could be improved.
> > > Per
uming.
That is more convincing. But do we need a GUC for that? What about
making a table eligible for autovacuum as soon as the number of dead
tuples reaches 90% of what you can hold in "autovacuum_work_mem"?
Yours,
Laurenz Albe
On Fri, 2024-04-26 at 09:35 +0200, Frédéric Yhuel wrote:
>
> Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
> > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > > I believe that the underlying problem here can be summarized in this
> > > way: just because
tty critical.
Yes. But I'd argue that that is a shortcoming of logical replication:
there should be a ways to get this information via SQL. Having to look into
the log file is not a very useful option.
The feature will become much less useful if unique voilations keep getting
logged.
Yours,
Laurenz Albe
n "pg_attribute".
I didn't try it, but I guess that the performance difference will be measurable.
So I wouldn't call it "syntactic sugar".
Perhaps: The behavior of the NOT NULL constraint is like that of a check
constraint with IS NOT NULL.
Yours,
Laurenz Albe
in ordinary backend processes.
Yours,
Laurenz Albe
From 3fe19a7df69d588d6a915450064094ca2066ae33 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 3 May 2024 14:47:03 +0200
Subject: [PATCH v3] Add parameter log_suppress_errcodes
The parameter contains a list of SQLSTATEs for which
FATAL and
gs I would like feedback about:
- is it OK to use "pg_read_all_stats" for that?
- should the check be moved to standard_ExplainOneQuery()?
Yours,
Laurenz Albe
From f31ee5919a9d30f51ff9d54adc7397cb98dfa370 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 6 May 2024 12:43:02
On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote:
> Attached is a POC patch that implements that (documentation and
> regression tests are still missing) to form a basis for a discussion.
... and here is a complete patch with regression tests and documentation.
Yours,
Laurenz Alb
"this is an SQL statement that will run on
a specific database with certain objects in it".
To me, "correct syntax" is the former.
Yours,
Laurenz Albe
ing?
> Withholding a commit?
I think it is a good rule. I don't think that it shouldn't lead to putting
people on the pillory or kicking their patches, but I imagine that a committer
looking for somebody else's patch to work on could prefer patches by people
who are doing their share of reviews.
Yours,
Laurenz Albe
actual minor-version-upgrade
> > extension breakages, so we can judge what caused them.
>
> Yes, that could be a fruitful discussion.
Digging through my commits brought up 6214e2b2280462cbc3aa1986e350e167651b3905,
for one.
Yours,
Laurenz Albe
w for that. This is not okay. But what should
> happen?
>
> 1. a CHECK(col IS NOT NULL) constraint is created for each column
> 2. a PRIMARY KEY () constraint is created
I think it would be best to create a primary key constraint on the
partition.
Yours,
Laurenz Albe
On Thu, 2022-08-18 at 11:04 +0200, Alvaro Herrera wrote:
> On 2022-Aug-18, Laurenz Albe wrote:
> > On Wed, 2022-08-17 at 20:12 +0200, Alvaro Herrera wrote:
> > > Using ALTER TABLE DROP CONSTRAINT works fine, and the 'attnotnull'
> > > bit is lost when t
d not HEAPTUPLE_DEAD?
Yours,
Laurenz Albe
On Tue, 2022-09-13 at 11:47 +0300, Nikita Malakhov wrote:
> On Tue, Sep 13, 2022 at 11:06 AM Laurenz Albe
> wrote:
> > Shouldn't such tuples be considered dead right away, even if the inserting
> > transaction is still active? That would allow cleaning them up even before
On Tue, 2022-09-13 at 16:13 +0200, Matthias van de Meent wrote:
> On Tue, 13 Sept 2022 at 15:45, Tom Lane wrote:
> > Laurenz Albe writes:
> > > But once they are deleted or updated, even the transaction that created
> > > them cannot
> > > see them any mor
other thread?
For reference: that was
https://postgr.es/m/f6a491b32cb44bb5daaafec835364f7149348fa1.ca...@cybertec.at
Yours,
Laurenz Albe
of what isn't normally part of "psql"
output.
"okbob" should be "Pavel Stehule".
Yours,
Laurenz Albe
g │ pg_get_viewdef │ text │ text, boolean
│ func
(17 rows)
A server function can be conveniently called from any client code.
Yours,
Laurenz Albe
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
I found two typos.
Yours,
Laurenz Albe
diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index faecae7c42..7dad0b8550 100644
--- a/doc/src/sgml/release
iew and define the order of fields if we need
> to display the fields of table in a order of our demand, it is not a
> good way.
But PostgreSQL tables are not spreadsheets. When, except in the display of
the result of interactive queries, would the order matter?
Yours,
Laurenz Albe
nd
> > this feature useful.
>
> Please see attached the patch that introduces this new feature.
Can you explain why *you* would find this feature useful?
Yours,
Laurenz Albe
d be faily trivial, if not very useful.
At a quick glance, it looks like you resolve "timezone" at the time
the query is parsed. Shouldn't the resolution happen at query
execution time?
Yours,
Laurenz Albe
n explicitly.
>
> We have never seen this before. Could this be a bug?
Impossible to say without a way to reproduce.
Yours,
Laurenz Albe
nal author, I'd say that that sounds reasonable, particularly
in case #1. If the postmaster dies, we are going to die too, so it
probably doesn't matter much. But I think an error is certainly also
correct in that case.
Yours,
Laurenz Albe
tests show that it is calculated
> at execution time.
Ah, ok, then sorry for the noise. I misread the code then.
Yours,
Laurenz Albe
t;fullsort_state = NULL;
}
if (node->prefixsort_state != NULL)
{
- tuplesort_reset(node->prefixsort_state);
+ tuplesort_end(node->prefixsort_state);
node->prefixsort_state = NULL;
}
The original comment hints that this might mot be the correct thing to do...
Yours,
Laurenz Albe
errmsg("Damn1! Update were done
> in a non-volatile function")));
I think it is project policy to start error messages with a lower case
character.
Yours,
Laurenz Albe
; public | parttest_10_7 | fdw_node5
> public | parttest_10_9 | fdw_node6
> (5 rows)
>
> (Muffled sound of small patch hatching) aha:
>
> postgres=# SELECT * FROM parttest;
> ERROR: user mapping not found for user "postgres", server "fdw_node5"
+1
Yours,
Laurenz Albe
ding jit=off for all but analytic workloads.
Yours,
Laurenz Albe
ing in a significant increase in the new
> cluster's size.
Please provide some numbers, ideally
du -sk
Yours,
Laurenz Albe
_test/pg_upgrade_testing/postgres_14/new_pg
> 11224524 /home/test/pradeep_test/pg_upgrade_testing/postgres_11.4/master
> 41952 /home/test/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
That looks fine. The files exist only once, and the 41MB that only exist in
the new data directory are catalog data and other stuff that is different
on the new cluster.
Yours,
Laurenz Albe
happy to let you take it -- got lots of other stuff on my plate.
>
> OK, will do.
It would be cool if we could get that into the next minor release in August.
Yours,
Laurenz Albe
On Sun, 2023-07-02 at 20:13 +0200, Tomas Vondra wrote:
> FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
> the report!
Thanks, and sorry for being pushy.
Yours,
Laurenz Albe
ubject should really be "Allow forcing UPDATEs off the same page".
I've been thinking about the same thing - an option that changes the update
strategy to always use the lowest block with enough free space.
That would allow to consolidate bloated tables with no down time.
Yours,
Laurenz Albe
CONTAINED_BY_RANGE ||
req->funcid == F_RANGE_CONTAINS_ELEM);
if (req->funcid == F_ELEM_CONTAINED_BY_RANGE)
{
[...]
}
else if (req->funcid == F_RANGE_CONTAINS_ELEM)
{
[...]
}
Yours,
Laurenz Albe
2 rows)
SELECT * FROM tx WHERE t <@ textrange('a', 'd');
ERROR: could not determine which collation to use for string comparison
HINT: Use the COLLATE clause to set the collation explicitly.
The replacement operators are wrong; it should be ~>=~ and ~<~ .
Also, there should be no error message.
The result should be 'a', 'c' and 'ch'.
Yours,
Laurenz Albe
ature to be
> useful.
Right, I agree. A GUC/storage parameter like "update_strategy"
that is an enum (try-hot | first-page | ...).
To preserve BRIN indexes or CLUSTERed tables, there could be an additional
"insert_strategy", but that would somehow have to be tied to a certain
index. I think that is out of scope for this effort.
Yours,
Laurenz Albe
quot;, for example
Index Cond (expr >= lower(range) AND expr < upper(range)).
Yours,
Laurenz Albe
On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > - A general reminder: single line comments should start with a lower case
> > letter and have to period in the end:
>
> Should it be "have not to
iticism, and I think the way you split up the patch set right
now
is as good as it probably gets. Ideally, one could say something like "we need
at least
patch 1 to 4, 5 and 6 are optional, but desirable, all others can easily be
deferred
to a later time".
Yours,
Laurenz Albe
-> * be false, due possible accepting invalidation message inside domain
> <--> * check. But now, the variable, and all dependencies are locked, so we
> <--> * don't need to repeat validation.
> <--> */
Much better.
Here is an improved version:
Although "svar" is freshly validated in this point, svar->is_valid can
be false, if an invalidation message ws processed during the domain check.
But the variable and all its dependencies are locked now, so we don't need
to repeat the validation.
Yours,
Laurenz Albe
tested, failed
>
> LGTM
>
> The new status of this patch is: Ready for Committer
Huh? Do you mean "tested, passes"?
Yours,
Laurenz Albe
On Wed, 2024-03-06 at 14:32 +0100, Laurenz Albe wrote:
> On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> > On 11/6/23 14:23, Laurenz Albe wrote:
> > > This behavior looks buggy to me. What do you think?
> > > I cannot imagine that it is a security problem, thou
nd
> hasn't noticed a problem because they never change their
> timezone setting, they might not appreciate us breaking it.
I hope that there are few cases of that in the field, and I think it
is OK to break them. After all, it can be fixed with a simple
ALTER TABLE foo ALTER id TYPE timestamptz;
If the session time zone is UTC, that wouldn't even require a rewrite.
I agree that it cannot be backpatched.
Yours,
Laurenz Albe
e that the operator ignores the collation, so
the result is correct. With equality, there is no such loophole.
I don't know what the correct fix would be. Perhaps just refusing to use
the index for equality comparisons with non-deterministic collations.
Yours,
Laurenz Albe
On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote:
> I played around with incremental backup yesterday and tried $subject
>
> The WAL summarizer is running on the standby server, but when I try
> to take an incremental backup, I get an error that I understand to mean
On Tue, 2024-07-16 at 18:36 +0100, Dean Rasheed wrote:
> On Mon, 6 May 2024 at 15:46, Laurenz Albe wrote:
> >
> > Currently, it is pretty easy to subvert the restrictions imposed
> > by row-level security and security_barrier views. All you have to
> > to is use EX
ut people index strings all the time.
Yours,
Laurenz Albe
r vote at "not okay", or
> change it to an abstention?
In that case I am against it. Against the "routinely" in particular.
Yours,
Laurenz Albe
d be extremely
careful with any changes in major releases that might require
rebuilding indexes.
This is where I side with Noah.
Yours,
Laurenz Albe
thy discussion around it.
Our development process isn't perfect, and it can be quite frustrating
for contributors. Sorry about that.
Yours,
Laurenz Albe
ht unduly increase the log volume.
I'm not trying to rush things, but I see little point in kicking a trivial
patch like this through many commitfests. If no committer wants to step
up and commit this, it should be rejected.
Yours,
Laurenz Albe
d be removed.
> --- a/doc/src/sgml/ref/pg_restore.sgml
> +++ b/doc/src/sgml/ref/pg_restore.sgml
> +
> + -A class="parameter">schema_variable
> + --variable= class="parameter">schema_variable
> +
> +
> +Restore a named schema variable only. Multiple schema variables may
> be specified with
> +multiple -A switches.
> +
> +
> +
Do we need that? We have no such option for functions and other non-relations.
And if we really want such an option for "pg_restore", why not for "pg_dump"?
Yours,
Laurenz Albe
On Fri, 2024-07-19 at 12:59 -0400, Robert Haas wrote:
Thanks for looking at this.
> On Fri, Jul 19, 2024 at 11:32 AM David Steele wrote:
> > I think it would be enough just to add a hint such as:
> >
> > HINT: this is possible when making a standby backup with little or no
> > activity.
>
> Tha
501 - 600 of 852 matches
Mail list logo
