o PostgreSQL, but not
part of it.
Yours,
Laurenz Albe
> A bit of polishing later, maybe like the attached.
That looks good to me.
Yours,
Laurenz Albe
ment was expected before this writing. If we look at the
> nextval_interval more carefully, we can find it would not flush the xlog every
> time even the sequence's cachesize is 1. Currently It happens every 32 times
> on the nextval_internal at the worst case.
Right, I didn't think of that. Still, I'm -1 on this performance regression.
Yours,
Laurenz Albe
oday and found this case].
I think that is a bad idea.
It will have an intolerable performance impact on OLTP queries, doubling
the number of I/O requests for many cases.
Perhaps it would make sense to document that you should never rely on
sequence values from an uncommitted transaction.
Yours,
Laurenz Albe
happening on attaching collation versions
> to indexes). But personally I can't summon the motivation to work
> on that, when ICU is the *only* such infrastructure that offers
> readily program-readable versioning.
Nobody will want to hear that, but the only really good solution would
be for
t be worth worrying about,
and they can always come and make a case for that symbol to be exported.
Yours,
Laurenz Albe
hey can dump with 8.3 and restire that.
Yours,
Laurenz Albe
relfilenode,
relname from pg_class");
int count = 100;
while (rs.next() && count-- > 0) {
System.out.print(".");
}
rs.close();
stmt.close();
System.out.println("");
conn.close();
}
}
Yours,
Laurenz Albe
t for context: the -docs thread that belongs to this is
https://www.postgr.es/m/20211001163938.ifg4ayrsjwd7r6zr%40localhost
Yours,
Laurenz Albe
mplicated questions when
we dig deeper, such as "what about whole-row references?", tilts my vote.
If it were for free, I would say +1. But given the ratio of potential
headache versus added real-life benefit, I find myself voting -1.
Still, it is cute!
Yours,
Laurenz Albe
it 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
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
w the statistics.
Yours,
Laurenz Albe
riable 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
Subject: [PATCH] Fix
uld
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
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
> > "pgs
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 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
> >
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 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: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
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 view
> > > of that, how about doubling PGSTAT_STAT_INTERVAL to 1000
> >
> > > milliseconds? That would mean slightly less up-to-d
ut the increase
in statistics messages, except in the case of lots of short-lived
sessions. But in that scenario you cannot have session statistics
without lots of extra messages, and such a workload has enough performance
problems as it is, so I don't think we have to specifically worry about it.
Yours,
Laurenz Albe
erve your immediate need:
After calling pg_terminate_backend(), you can attach gdb to the backend and
then run
print ProcessInterrupts()
That will cause the backend to exit normally without crashing the server.
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 sen
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-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
t is useful enough to break the standard in a way that may be
incompatible with future extensions of the standard.
Yours,
Laurenz Albe
han 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
ancel 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
erformance. 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
s more performance or is complicated would not
be worth the effort.
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
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
unctions"
> 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
nting 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
ding 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
ollowing error:
> "All non-template0 databases must allow connections, i.e. their
> pg_database.datallowconn must be true; database "mydb" has datallowconn set
> to false."
I am in favor of that in principle, but I think that additional information
should be separate line.
Yours,
Laurenz Albe
https://www.postgresql.org/message-id/514fe5ce4714b7b33cb0a611f0c7b72df413bef5.camel%40cybertec.at
I think that is much better.
I am fine with that patch.
Yours,
Laurenz Albe
tly because it saves planning time,
partly because those can be useful tools.
Generally I have the impression that we are not too keen on spending
planning time on optimizing cases that can be trivially improved by rewriting
the query.
Yours,
Laurenz Albe
them.
I think reducing functionality should be the last route to consider.
If we introduce new syntax to access partitions, we will end up with a lot
of new syntax, and we might well have an endless stream of requests for
ways to do X with a partition.
Yours,
Laurenz Albe
t; + success_count == 1 ? "The" : "All",
> + success_count,
> + success_count == 1 ? "" : "s");
... and that wouldn't be translatable.
Yours,
Laurenz Albe
ndexscan = off;
> SET enable_bitmapscan = off;
>
> And then the data was returned properly.
Sounds like data corruption.
REINDEX the index and see if that fixes the problem.
Try to figure out the cause (bad hardware?).
Yours,
Laurenz Albe
t here;
> and I do not see why being spec-compliant for one case when we are not
> for the other is a good situation to be in.
+1
Yours,
Laurenz Albe
as this can cause subtle bugs. See
Subtle? Perhaps "bugs that are hard to find".
+src/backend/utils/cache/syscache.c,
+src/backend/utils/cache/relcache.c,
+src/backend/access/common/relation.c and their
+headers for details.
+
+
Attached i
d issue a warning.
That is simple, but coarse.
A slightly more sophisticated version would first check if files
are the same on both machines and skip the warning for those.
- Paul's idea to try and change the mode on the read-only file
and reset it to the original state after pg_rewind is done.
Yours,
Laurenz Albe
explicitly says otherwise (for example, recovery.signal
for archive recovery).
Yours,
Laurenz Albe
On Wed, 2021-05-05 at 11:55 +0200, Laurenz Albe wrote:
> On Wed, 2021-04-28 at 13:24 +0200, Laurenz Albe wrote:
> > On Tue, 2021-04-27 at 14:26 +, PG Doc comments form wrote:
> > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions
> > > the
&g
On Wed, 2021-05-05 at 12:03 +0200, Laurenz Albe wrote:
> On Mon, 2021-05-03 at 13:48 -0300, Martín Marqués wrote:
> > We should add a line that indicates that there is a limitation (that
> > should be IMO, backported to documentation of earlier versions as it
> > affects a
On Wed, 2021-05-19 at 10:31 -0400, Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > I revently tried to upgrade a standby following the documentation,
> > but I found it hard to understand, [...]
>
> Haven't had a chance to look at this in depth but
I would like to add a thread on pgsql-docs to the commitfest, but I
found that that cannot be done.
What is the best way to proceed?
Since we have a "documentation" section in the commitfest, it would
be useful to allow links to the -docs archives.
Yours,
Laurenz Albe
uster
is in charge of vacuuming its own tables, so the better approach would
be to tune autovacuum on the remote side so that it does the right thing.
Yours,
Laurenz Albe
server log which is a risky thing
> from security standpoint.
I think that is irrelevant.
A superuser can already set "log_statement = 'all'" to get this.
There is no protection from superusers, and it is pointless to require that.
Yours,
Laurenz Albe
previous query or a file with psql's \e, or using \ef
> and \ev, ignore the contents if the editor exits without saving (Laurenz Albe)
>
>
>
> Previously, such edits would still execute the editor contents.
>
>
That is fine with me and probab
On Mon, 2021-05-10 at 12:38 -0400, Bruce Momjian wrote:
> I came up with this release note text:
>
>
>
>
>
> When editing the previous query or a file with psql's \e, ignore the
> contents if the editor exits with
On Mon, 2021-05-10 at 02:03 -0400, Bruce Momjian wrote:
> When using \e in psql, if the buffer is not modified by the editor, ignore
> the editor contents and leave the buffer unchanged (Laurenz Albe)
> The \ef and \ev commands also now have this behavior. DOCS SAY BUFFER IS
> CL
, and I can measure the lag in bytes.
What more could you want?
Yours,
Laurenz Albe
mode, it says "... but if
> none of the listed hosts is a standby server, try again in all mode".
> There is no such "all" mode. It should instead say "any" mode.
> Patch is attached.
You are right, and the patch is good.
Yours,
Laurenz Albe
; inaccurate for example in that the current wording for "host" appears to
> say that it does not apply to GSS-encrypted connections.
+1
Thanks for taking care of things like that.
Yours,
Laurenz Albe
s. In languages other than Turkish, "i" is the lower case version of "I",
and both are ASCII. Only Turkish has an "ı" (U+0131) and an "İ" (U+0130).
That causes annoyance for Turks who create a table named KADIN and find
that PostgreSQL turns it into "kadin".
Yours,
Laurenz Albe
>
>1
>2
> (2 rows)
It is well known that synchronous replication is sublect to that problem,
since it doesn't use the two-phase commit protocol.
What surprises me is that this is a warning.
In my opinion it should be an error.
Yours,
Laurenz Albe
is a procedural language as the name suggests, you probably don't have
to modify PostgreSQL core code to make it work.
Yours,
Laurenz Albe
On Sat, 2021-04-03 at 17:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > Attached is version 6.
>
> Pushed with some mostly-cosmetic fiddling.
>
> One thing I changed that wasn't cosmetic is that as you had it,
> the behavior of "\e file" varied depending
"Either use a later backup, or recover to a point in time before \"wal_level\"
was set to \"minimal\"."
I'd say that we can leave it to the intelligence of the reader to
deduce that recovering to an earlier time means more data loss.
Yours,
Laurenz Albe
problem.
I don't know if Seamus is still working on that; if not, we might
mark it as "returned with feedback".
Perhaps Amit's patch 0001 should go in independently.
I'll mark the patch as "waiting for author".
Yours,
Laurenz Albe
On Mon, 2021-03-15 at 17:09 +, Bossart, Nathan wrote:
> On 3/15/21, 7:06 AM, "Laurenz Albe" wrote:
> > On Fri, 2021-03-12 at 21:41 +, Bossart, Nathan wrote:
> > > On 3/12/21, 11:14 AM, "Joe Conway" wrote:
> > > > Looking back at the
0xffe0 && ucs <= 0xffe6) ||
- (ucs >= 0x2 && ucs <= 0x2)));
+ (ucs >= 0x2 && ucs <= 0x2) ||
+ (ucs >= 0x1f300 && ucs <= 0x1faff))); /* symbols and emojis */
}
/*
This is guesswork based on the unicode entries that look like symbols.
Yours,
Laurenz Albe
nce NaN is the result of operations like 0/0 or infinity - infinity,
> > NULL might be better.
> > So I'd opt for NULL too.
>
> Thanks. Do you think it's acceptable that returning false instead of
> NULL as an alternative behavior?
Yes, I think that is acceptable.
Yours,
Laurenz Albe
st in solving this.
Thank you for your willingness to help!
Sure, this is the place to discuss your idea, go ahead.
Right now is the end of the final commitfest for v14, so people
are busy getting patches committed and you may get less echo than normally.
Yours,
Laurenz Albe
omparison return NULL? If you
> agree to that, I'll make a further change to the patch.
If you think of "NaN" literally as "not a number", then FALSE would
make sense, since "not a number" implies "not a number between 0 and 1".
But since NaN is the result of operations like 0/0 or infinity - infinity,
NULL might be better.
So I'd opt for NULL too.
Yours,
Laurenz Albe
ks the
> condition using point_inside() / lseg_crossing(), while the gist index will
> check the condition using box_overlap() / box_ov(), which have different
> opinions on how to handle NaN.
>
> Getting a consistent behavior shouldn't be hard, but I'm unsure which behavior
> is actually correct.
I'd say that this is certainly wrong:
SELECT point('NaN','NaN') <@ polygon('(0,0),(1,0),(1,1),(0,0)');
?column?
--
t
(1 row)
Yours,
Laurenz Albe
ed a
> > rollup patch, equivalent to applying all five patches.
>
> I committed prerequisites from one thread, so here's a rebased rollup patch.
I am happy to see this problem tackled!
Yours,
Laurenz Albe
On Mon, 2021-03-22 at 13:22 -0400, Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > On Mon, 2021-03-22 at 11:05 -0400, Stephen Frost wrote:
> > > > Perhaps allowing to set unlogged tables to logged ones without writing
> > > > WAL
&g
bers that it is not crash safe and is
emptied if there is a crash before the next checkpoint?
Wouldn't that cause corruption if you restore from an earlier backup?
At least with the feature in this thread we'd get an error on recovery.
Yours,
Laurenz Albe
ee how that would be any
more crash safe than this patch. Besides, the feature doesn't exist yet.
So I think that argument doesn't carry much weight.
Yours,
Laurenz Albe
d see if any of them can be
> > used/improved to achieve the desired result?
>
> Other methods are not as easy-to-use, and more complex to implement.
Fast and loose often takes less effort, yes.
Yours,
Laurenz Albe
gt; a new base backup.")));
>
> into a PANIC instead of a WARNING.
There is a patch in the commitfest that does exactly that (except it
uses ERROR rather than PANIC):
https://postgr.es/m/osbpr01mb4888cbe1da08818fd2d90ed8ed...@osbpr01mb4888.jpnprd01.prod.outlook.com
Yours,
Laurenz Albe
on't expect it to be executed again.
Currently, the only way to achieve that is to empty the temporary
file and then save it, which is annoying.
Attached is version 6.
Yours,
Laurenz Albe
From 436f48e21adcf207dc267db834a2e80f846fb666 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 15 Mar 2021
gt;
> That seems reasonable to me.
+1 from me too.
Yours,
Laurenz Albe
ing "role" in a libpq connect string might be
worth documenting. Can you think of a use case?
Yours,
Laurenz Albe
From 5daa6c2a874898506fda316fe651f107dbed34d5 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 12 Mar 2021 15:32:01 +0100
Subject: [PATCH] Document ALTER ROLE ... SET ROLE
T
ER ROLE, perhaps ALTER DATABASE
(although I don't see what sense it could make to set that on the database
level),
and briefly explain the difference between RESET ROLE and SET ROLE NONE.
I think adding too much detail will harm - anyone who needs to know the
exact truth can resort to the implementat
the user identifier to the
value it had after you connected to the database. This can be different
from the session identifier if ALTER DATABASE or
ALTER ROLE were used to assign a different default role.
(I hope what I wrote is correct.)
Yours,
Laurenz Albe
that some Microsoft filesystems have 2-second
> resolution on file mod times, so maybe it needs to be "time(NULL) - 2"?
Thanks for taking a look!
Taken together, these arguments are convincing.
Done like that in the attached patch version 4.
Yours,
Laurenz Albe
From 31257c2e697
d agree with you and forbid it in HEAD
as a corner case with little real-world use.
Yours,
Laurenz Albe
pgbench_accounts from stdin");
> + res = PQexec(con, "copy pgbench_accounts from stdin freeze");
I think it would be better to use the official syntax and put the "freeze"
in parentheses. Perhaps the old syntax will be desupported some day.
Yours,
Laurenz Albe
On Fri, 2021-03-05 at 22:55 +0900, Amit Langote wrote:
> On Fri, Mar 5, 2021 at 10:47 PM Laurenz Albe wrote:
> > On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> > > For example, with the attached PoC patch:
> >
> > I have incorporated your POC pat
On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> For example, with the attached PoC patch:
I have incorporated your POC patch and added a regression test.
I didn't test it thoroughly though.
Yours,
Laurenz Albe
From 34f7da98b34bc1dbf7daca9e2ca6055c80d77f43 Mon Sep 17 00:00:00 2001
F
t any save is guaranteed
> to move the timestamp forward. That should work even if the filesystem
> has extremely poor precision.
Ah, of course, that is the way to go.
Attached is version 3 which does it like this.
Yours,
Laurenz Albe
From 7ff01271cb8ea5c9011a57ed613026ec7511d785 Mon Sep 17 00:00:00
On Wed, 2021-03-03 at 17:12 +, Jacob Champion wrote:
> On Wed, 2021-03-03 at 17:08 +0100, Laurenz Albe wrote:
> > This is no new behavior, and I think this is rare enough that we don't
> > have to bother.
>
> I agree that it's not new behavior, but this patch ex
On Wed, 2021-03-03 at 17:58 +0900, Amit Langote wrote:
> On Tue, Mar 2, 2021 at 5:47 PM Laurenz Albe wrote:
> > On Tue, 2021-03-02 at 11:23 +0900, Amit Langote wrote:
> > > I got the same result with my implementation, but I am wondering if
> > > setting parallel_wo
Thanks for testing!
On Wed, 2021-03-03 at 00:07 +, Jacob Champion wrote:
> On Wed, 2020-12-16 at 10:45 +0100, Laurenz Albe wrote:
>
> > I consider this a bug fix, but one that shouldn't be backpatched.
> > Re-executing the previous query if the editor is quit is
>
Seq Scan on pagg_tab_ml_p2_s2 pagg_tab_ml_2
(14 rows)
The default number of parallel workers is taken, because the append is
on an upper relation, not the partitioned table itself.
One would wish that "parallel_workers" somehow percolated up, but I
have no idea how that should work.
Yours,
Laurenz Albe
I'm thinking it would be better to just modify the existing macro to
> check relkind to decide which struct pointer type to cast the value in
> rd_options to.
Here is an updated patch with this fix.
I added regression tests and adapted the documentation a bit.
I also added support for lowerin
hink that if the option is set, it should override the number of workers
inherited from the partitions, and it should override the log2 default.
Yours,
Laurenz Albe
e re-purpose "parallel_workers" like this, we'd have to change this.
Then for a normal table, "parallel_workers" would mean how many workers
work on a parallel table scan. For a partitioned table, it determines
how many workers work on a parallel append.
Perhaps that is similar enough that it is not confusing.
Yours,
Laurenz Albe
d: if the executor prunes some
partitions, the degree of parallelism is unaffected, right?
So if the planner decides to use 24 workers for 25 partitions, and the
executor discards all but one of these partition scans, we would end up
with 24 workers scanning a single partition.
I am not sure how that could be improved.
Yours,
Laurenz Albe
On Mon, 2021-02-01 at 23:33 +0900, Masahiko Sawada wrote:
> I've closed this commitfest. If you have feedback or comment on my CFM
> work, please tell me here or by directly emailing me.
I think you did an excellent job.
Yours,
Laurenz Albe
rmal transaction rollback steps,
but issue an error message.
At least we should fake it well...
Yours,
Laurenz Albe
On Tue, 2021-01-26 at 11:09 -0500, Dave Cramer wrote:
> On Tue, 26 Jan 2021 at 05:05, Laurenz Albe wrote:
>
> > I wonder about the introduction of the new USER_ERROR level:
> >
> > #define WARNING_CLIENT_ONLY20 /* Warnings to be sent
I think that this needs some more comments to
make this clear.
Is this new message level something we need to allow setting for
"client_min_messages" and "log_min_messages"?
Yours,
Laurenz Albe
301 - 400 of 685 matches
Mail list logo
