On Sat, Jun 04, 2022 at 12:35:45PM +0900, Michael Paquier wrote:
> Something like 80~85% of the bloat comes from the diffs in your case.
> Well, it is always possible to limit that to an arbitrary amount of
> characters (say 50k~100k?) to still give some context, and dump the
> whole in a different
On Fri, Jun 03, 2022 at 12:53:18PM -0700, Andres Freund wrote:
> [...]
TRAP: FailedAssertion("AmIoWorkerProcess()", File: "xlog.c", Line:
4860, PID: 35325)
> regress_log_002_pg_upgrade.log includes all of 002_pg_upgrade_old_node.log and
> 002_pg_upgrade_new_node.log. The old node's log includes a
Hi,
I just saw a pg_upgrade failure on my aio branch [1]. Not sure what caused it
yet. The reason I'm writing in this thread is that I looked at the
regress_log_* for the failure, and found it to be 14.95MiB (which crashed the
browser on my phone...).
https://api.cirrus-ci.com/v1/artifact/task/51
On Fri, May 20, 2022 at 06:28:01PM -0700, Noah Misch wrote:
> Looks successful.
Thanks a lot for confirming. I have applied that on HEAD, then.
--
Michael
signature.asc
Description: PGP signature
On Wed, May 18, 2022 at 06:20:08PM +0900, Michael Paquier wrote:
> Attached is an updated patch to address your concerns.
Looks successful.
On Wed, May 18, 2022 at 01:03:15AM -0700, Noah Misch wrote:
> On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote:
>> Because the shape of the new names does not change the test coverage
>> ("regression" prefix or the addition of the double quotes with
>> backslashes for all the databas
On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote:
> On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote:
> > Here, I requested the rationale for the differences you had just described.
> > You made a choice to stop testing one list of database names and start
> > testing
> >
On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote:
> Here, I requested the rationale for the differences you had just described.
> You made a choice to stop testing one list of database names and start testing
> a different list of database names. Why?
Because the shape of the new names
On Thu, May 12, 2022 at 02:27:30PM +0900, Michael Paquier wrote:
> On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote:
> > On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote:
> > > On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> > > > All these fixes lead me
On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote:
> Why did you discontinue testing the longstanding test database name?
I am not sure what you mean here. Are you saying that the test should
be changed to prefix each database name by "regression", as it was the
case in test.sh? Or do y
On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote:
> On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> > All these fixes lead me to the attached patch.
>
> I have applied this stuff as of 7dd3ee5, in time for beta1, and closed
> the open item. One difference is that
On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> All these fixes lead me to the attached patch.
I have applied this stuff as of 7dd3ee5, in time for beta1, and closed
the open item. One difference is that I've added one backslash
surrounding the double quote at the beginning *an
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote:
> On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
>> commit 322becb wrote:
>
> Nothing checks the command result, so the test file passes even if each of
> these createdb calls fails. Other run_log() calls in this file ha
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote:
> commit 322becb wrote:
Thanks, Noah. I am out this week, but I should be able to address all
your points at the beginning of next week. I have added an open item
for now.
--
Michael
signature.asc
Description: PGP signature
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
> On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote:
> > Well, let's go ahead with it and see what happens. If it's too
> > much of a mess we can always revert.
>
> Okay, done after an extra round of self-review.
commit 322b
On Fri, Apr 01, 2022 at 08:34:34AM -0500, Justin Pryzby wrote:
> If you do that, should also remove upgradecheck from .cirrus.yaml, which
> currently runs the upgradecheck target.
Indeed. It makes no sense to keep that. I have removed this part and
applied the patch, after one extra run through
On Fri, Apr 01, 2022 at 08:53:10PM +0900, Michael Paquier wrote:
> On Fri, Apr 01, 2022 at 03:01:38PM +0900, Michael Paquier wrote:
> > On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote:
> >> Is diff -q defined somewhere ? I can't find it in postgres sources nor in
> >> sources for bf
On Fri, Apr 01, 2022 at 03:01:38PM +0900, Michael Paquier wrote:
> On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote:
>> Is diff -q defined somewhere ? I can't find it in postgres sources nor in
>> sources for bf client.
>
> 322becb has added such a call, at the end of 002_pg_upgrade.
On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote:
> Is diff -q defined somewhere ? I can't find it in postgres sources nor in
> sources for bf client.
322becb has added such a call, at the end of 002_pg_upgrade.pl.
vcregress.pl also has one before this commit.
--
Michael
signature.
On Thu, Mar 31, 2022 at 08:42:41PM -0700, Noah Misch wrote:
> The failure looked like this:
>
> # Running: diff -q
> /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_lPFv/dump1.sql
>
> /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrad
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
> Okay, done after an extra round of self-review. I have finished by
> tweaking a couple of comments, and adjusted further TESTING to explain
> what needs to be done to have a dump compatible with the test. Let's
> now see what goes
On Thu, Mar 31, 2022 at 08:42:41PM -0700, Noah Misch wrote:
> On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
> > On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote:
> > > Well, let's go ahead with it and see what happens. If it's too
> > > much of a mess we can always rever
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
> On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote:
> > Well, let's go ahead with it and see what happens. If it's too
> > much of a mess we can always revert.
>
> Okay, done after an extra round of self-review. I have fini
On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote:
> Well, let's go ahead with it and see what happens. If it's too
> much of a mess we can always revert.
Okay, done after an extra round of self-review. I have finished by
tweaking a couple of comments, and adjusted further TESTING to expl
Michael Paquier writes:
> On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote:
>> On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
>>> How well does this patch work with pre-14 buildfarm clients?
>> Looks to me like it'll just run the test twice, once via TestUpgrade, once
>> via
>> tapte
On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote:
> On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
> > How well does this patch work with pre-14 buildfarm clients?
>
> Looks to me like it'll just run the test twice, once via TestUpgrade, once via
> taptest. It's possible that there cou
On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
> How well does this patch work with pre-14 buildfarm clients?
Looks to me like it'll just run the test twice, once via TestUpgrade, once via
taptest. It's possible that there could be trouble somehow due to duplicated
log files or something?
I wrote:
> There's still about a third of the buildfarm running older
> client releases --- I count
> 2 REL_8
> 2 REL_10
> 13 REL_11
> 6 REL_12
> 16 REL_13.1
> 89 REL_14
Wait a minute ... actually, what's most relevant here is
the population running TAP tests, whi
Michael Paquier writes:
> So, any particular feelings about this patch? This has been around
> for a couple of months/years now, so it could be a good time to do the
> switch now rather than wait an extra year, or even the beginning of
> the next release cycle. And the buildfarm is already able
On Thu, Mar 03, 2022 at 02:03:38PM +0900, Michael Paquier wrote:
> Indeed. I have reworked the whole, rather than just those three
> sentences.
So, any particular feelings about this patch? This has been around
for a couple of months/years now, so it could be a good time to do the
switch now rat
On 3/3/22 00:03, Michael Paquier wrote:
>>> +if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall}))
>>> + || (!defined($ENV{olddump}) && defined($ENV{oldinstall})))
>> Odd indentation. Spaces between parens?
> Well, perltidy tells me that this is right.
>
>
Yeah, I haven't found a way t
On Wed, Mar 02, 2022 at 12:07:29AM -0800, Andres Freund wrote:
>> +++ b/src/bin/pg_upgrade/t/001_basic.pl
>> @@ -0,0 +1,9 @@
>> +use strict;
>> +use warnings;
>> +
>> +use PostgreSQL::Test::Utils;
>> +use Test::More tests => 8;
>
> Outdated.
Fixed.
>> +program_help_ok('pg_upgrade');
>> +program_
On Wed, Mar 02, 2022 at 12:01:17AM -0800, Andres Freund wrote:
> But in a bad way, because EXTRA_REGRESS_OPTS now always wins, even for stuff
> we want to override. Note how test.sh explicitly specifies port, bindir etc
> after the pre-existing EXTRA_REGRESS_OPTS.
Ah, right. Will fix.
--
Michael
Hi,
On 2022-03-02 15:57:23 +0900, Michael Paquier wrote:
> Do others have an opinion about a backpatch of the bugfix? Nobody has
> complained about that since pg_upgrade exists, so I have just done the
> change on HEAD.
WFM.
> +++ b/src/bin/pg_upgrade/t/001_basic.pl
> @@ -0,0 +1,9 @@
> +use s
On 2022-02-15 13:02:41 +0900, Michael Paquier wrote:
> >> + @regress_command = (@regress_command, @extra_opts);
> >> +
> >> + $oldnode->command_ok(@regress_command,
> >> + 'regression test run on old instance');
> >
> > I also think this should take EXTRA_REGRESS_OPTS into account - tes
On Wed, Feb 16, 2022 at 01:58:10PM +0900, Michael Paquier wrote:
> I have been looking at how much simplicity this brings, and I have to
> admit that it is tempting to just support the loading of dumps when
> setting up the old instance to upgrade from. We'd still need to do an
> extra effort in t
On Tue, Feb 15, 2022 at 01:02:41PM +0900, Michael Paquier wrote:
> Hmm. At the end of the day, I am wondering whether we should not give
> up entirely on the concept of running the regression tests on older
> branches in the TAP script of a newer branch. pg_regress needs to
> come from the old so
On Sat, Feb 12, 2022 at 08:50:41PM -0800, Andres Freund wrote:
> On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
>> +# required for 002_pg_upgrade.pl
>> +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
>> +export REGRESS_SHLIB
>
> It seems weird to propagate this into mu
On Sat, Feb 12, 2022 at 08:12:42PM -0800, Andres Freund wrote:
> It also doesn't handle @ correctly. Makes sense to fix. Should probably use
> the same logic that libpq, psql, ... use?
>
> if (is_unixsock_path(ch->host))
> ch->type = CHT_UNIX_SOC
On Sun, Feb 13, 2022 at 02:55:26PM -0800, Andres Freund wrote:
> On 2022-02-14 11:23:18 +1300, Thomas Munro wrote:
>> Ahh, right. I assume it still needs perl2host() treatment for MSYS2
>> systems, because jacana's log shows TESTDIR is set to a Unixoid path
>> that I assume pg_regress's runtime ca
On 2022-02-14 11:23:18 +1300, Thomas Munro wrote:
> On Sun, Feb 13, 2022 at 6:29 PM Andres Freund wrote:
> > Afaics all the "regress test inside tap test" cases would need to do is to
> > pass
> > --outputdir=${PostgreSQL::Test::Utils::tmp_check} and you'd get exactly the
> > same path as
> > RE
On Sun, Feb 13, 2022 at 6:29 PM Andres Freund wrote:
> Afaics all the "regress test inside tap test" cases would need to do is to
> pass
> --outputdir=${PostgreSQL::Test::Utils::tmp_check} and you'd get exactly the
> same path as
> REGRESS_OUTPUTDIR currently provides.
Ahh, right. I assume it
Hi,
On 2022-02-13 18:07:30 +1300, Thomas Munro wrote:
> On Sun, Feb 13, 2022 at 5:50 PM Andres Freund wrote:
> >> > +# required for 027_stream_regress.pl
> >> > +REGRESS_OUTPUTDIR=$(abs_top_builddir)/src/test/recovery
> >> > +export REGRESS_OUTPUTDIR
> >>
> >> Why do we need this?
> >
> > The Mak
Thomas Munro writes:
> I thought it was a goal that VPATH builds shouldn't pollute the source
> tree, but the Make macro prove_check is explicitly doing so by
> default. Perhaps *that* should be fixed?
Indeed. That seems broken by definition.
More generally, I thought we'd established a conven
On Sun, Feb 13, 2022 at 5:50 PM Andres Freund wrote:
> On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
> > +REGRESS_OUTPUTDIR=$(abs_top_builddir)/src/bin/pg_upgrade
> > +export REGRESS_OUTPUTDIR
>
> I don't really understand why 027_stream_regress.pl is using this (and thus
> not why it's use
Hi,
On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
> +# required for 002_pg_upgrade.pl
> +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
> +export REGRESS_SHLIB
It seems weird to propagate this into multiple places. Why don't we define
that centrally?
Although it's w
Hi,
On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
> On Sat, Jan 15, 2022 at 01:52:39PM +0800, Julien Rouhaud wrote:
> > libpq environment variable PGHOST has a non-local server value:
> > C:/Users/ContainerAdministrator/AppData/Local/Temp/FhBIlsw6SV
> > Failure, exiting
> > not ok 3 - run
On Sat, Jan 15, 2022 at 01:52:39PM +0800, Julien Rouhaud wrote:
> libpq environment variable PGHOST has a non-local server value:
> C:/Users/ContainerAdministrator/AppData/Local/Temp/FhBIlsw6SV
> Failure, exiting
> not ok 3 - run of pg_upgrade for new instance
There are two things here, as far as
Hi,
On Tue, Jan 11, 2022 at 04:14:25PM +0900, Michael Paquier wrote:
> The CF bot is unhappy, so here is a rebase, with some typo fixes
> reported by Justin offlist.
The cfbot still complains about this patch on Windows:
https://cirrus-ci.com/task/6411385683836928
https://api.cirrus-ci.com/v1/art
On Wed, Jan 05, 2022 at 05:12:41PM +0900, Michael Paquier wrote:
> Rebased patch to cool down the CF bot, as per the addition of
> --no-sync to pg_upgrade.
The CF bot is unhappy, so here is a rebase, with some typo fixes
reported by Justin offlist.
--
Michael
From 1d2dc68b8c27d9c328276ed21e57290f6
On Thu, Dec 16, 2021 at 11:51:55AM +0900, Michael Paquier wrote:
> I may have missed one thing or two, but I think that's pretty much
> what we should be looking for to do the switch to TAP in terms of
> coverage.
Rebased patch to cool down the CF bot, as per the addition of
--no-sync to pg_upgrad
On Wed, Dec 15, 2021 at 10:47:24AM +0900, Michael Paquier wrote:
> Missed that, thanks! I'll think about all that a bit more before
> sending a long-overdue rebased version.
Okay, here is finally a rebase of this patch, where I have fixed a
couple of existing issues, and I have extended the patch
On Mon, Dec 13, 2021 at 10:14:49PM -0800, Andres Freund wrote:
> Tom's point was that the buildfarm scripts do
> if ($self->{bfconf}->{using_msvc})
> @checklog = run_log("perl vcregress.pl upgradecheck");
> else
> "cd $self->{pgsql}/src/bin/pg_upgra
On 2021-12-14 14:31:24 +0900, Michael Paquier wrote:
> On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> > Seems like we might get away with making make -C contrib/pg_upgrade check
> > and
> > vcregress.pl upgradecheck do nothing?
>
> You mean #contrib/#src/bin/# here, right? I do
On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> Seems like we might get away with making make -C contrib/pg_upgrade check and
> vcregress.pl upgradecheck do nothing?
You mean #contrib/#src/bin/# here, right? I don't think that we have
any need to have "make -C" do nothing. For v
Hi,
On 2021-10-02 23:34:38 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 10/2/21 5:03 PM, Tom Lane wrote:
> >> IIUC, the only problem for a non-updated animal would be that it'd
> >> run the test twice? Or would it actually fail? If the latter,
> >> we'd need to sit on the patch rather
On Mon, Oct 11, 2021 at 09:04:47AM -0400, Andrew Dunstan wrote:
> Keeping test.sh is not necessary - I mis-remembered what the test module
> does.
So.. Are people fine to remove entirely test.sh at the end, requiring
the tests of pg_upgrade to have TAP installed? I'd rather raise the
bar here, a
On Sun, Oct 03, 2021 at 08:22:57AM -0400, Andrew Dunstan wrote:
> Actually, I was wrong. The module just does "make check" for non-MSVC.
> For MSVC it calls vcregress.pl, which the patch doesn't touch (it
> should, I think).
Yes, it should. And I'd like to do things so as we replace all the
inter
On 10/10/21 10:07 AM, Peter Eisentraut wrote:
> On 03.10.21 09:03, Michael Paquier wrote:
>> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
>>> Maybe we could leave test.sh in place for awhile? I'd rather
>>> not cause a flag day for buildfarm owners. (Also, how do we
>>> see this wo
On Sun, Oct 10, 2021 at 04:07:43PM +0200, Peter Eisentraut wrote:
> On 03.10.21 09:03, Michael Paquier wrote:
>> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
>>> Maybe we could leave test.sh in place for awhile? I'd rather
>>> not cause a flag day for buildfarm owners. (Also, how do
On 03.10.21 09:03, Michael Paquier wrote:
On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
Maybe we could leave test.sh in place for awhile? I'd rather
not cause a flag day for buildfarm owners. (Also, how do we
see this working in the back branches?)
I would be fine with test.sh st
On 10/2/21 11:34 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/2/21 5:03 PM, Tom Lane wrote:
>>> IIUC, the only problem for a non-updated animal would be that it'd
>>> run the test twice? Or would it actually fail? If the latter,
>>> we'd need to sit on the patch rather longer.
>> The
On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
> Maybe we could leave test.sh in place for awhile? I'd rather
> not cause a flag day for buildfarm owners. (Also, how do we
> see this working in the back branches?)
I would be fine with test.sh staying around for now.
If we do that, th
Andrew Dunstan writes:
> On 10/2/21 5:03 PM, Tom Lane wrote:
>> IIUC, the only problem for a non-updated animal would be that it'd
>> run the test twice? Or would it actually fail? If the latter,
>> we'd need to sit on the patch rather longer.
> The patch removes test.sh, so yes it would break.
On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I haven't looked at the patch closely yet, but from a buildfarm POV I
>> think the only thing that needs to be done is to inhibit the buildfarm
>> client module if the TAP tests are present. The buildfarm code that runs
>> TAP tests
Andrew Dunstan writes:
> I haven't looked at the patch closely yet, but from a buildfarm POV I
> think the only thing that needs to be done is to inhibit the buildfarm
> client module if the TAP tests are present. The buildfarm code that runs
> TAP tests should automatically detect and run the new
On 10/1/21 2:19 AM, Michael Paquier wrote:
> On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote:
>> This stuff still needs to be expanded depending on how PostgresNode is
>> made backward-compatible, but I'll wait for that to happen before
>> going further down here. I have also spe
On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote:
> This stuff still needs to be expanded depending on how PostgresNode is
> made backward-compatible, but I'll wait for that to happen before
> going further down here. I have also spent some time testing all that
> with MSVC, and the
On Tue, Sep 07, 2021 at 02:43:15PM -0700, Rachel Heaton wrote:
> Running check tests in the pg_upgrade folder fails for this reason.
Thanks, rebased as attached. Andrew has posted another patch set that
completely reworks the shape of the modules by moving them into a
dedicated namespace, meaning
Hello Michael,
This patch needs the update from 201a76183 -- the function `get_new_node`
no longer exists.
Running check tests in the pg_upgrade folder fails for this reason.
Thank you,
Rachel
On Tue, Sep 7, 2021 at 2:06 PM Michael Paquier wrote:
> On Tue, May 18, 2021 at 10:49:39AM +0900, Mi
On Tue, May 18, 2021 at 10:49:39AM +0900, Michael Paquier wrote:
> Makes sense. For now, I'll update this patch set so as it is possible
> to use custom dumps, as an option in parallel of pg_regress when
> specifying a different source code path. I'll also decouple the
> business with probin upda
On Mon, May 17, 2021 at 12:32:13PM -0400, Andrew Dunstan wrote:
> On 5/16/21 9:55 PM, Michael Paquier wrote:
> Yes, I'm going to be proposing a series of smallish patches including
> these when the tree is branched (which I hope will be in a few weeks).
Thanks! That clearly needs to happen first.
On 5/16/21 9:55 PM, Michael Paquier wrote:
> On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote:
>> PostgresNode is currently able to create nodes suitable for upgrade down
>> to release 10. If we add '-w' to the 'pg_ctl start' flags that can
>> extend down to release 9.5. (Just teste
On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote:
> PostgresNode is currently able to create nodes suitable for upgrade down
> to release 10. If we add '-w' to the 'pg_ctl start' flags that can
> extend down to release 9.5. (Just tested) I think we should do that
> forthwith. '-w' is
On 5/14/21 10:26 PM, Michael Paquier wrote:
> Hi,
> (Adding Andrew in CC for the buildfarm and PostgresNode parts.)
>
> $subject has been around for a couple of years now, with the following
> threads:
> https://www.postgresql.org/message-id/20180126080026.gi17...@paquier.xyz
> https://www.postgr
Hi,
(Adding Andrew in CC for the buildfarm and PostgresNode parts.)
$subject has been around for a couple of years now, with the following
threads:
https://www.postgresql.org/message-id/20180126080026.gi17...@paquier.xyz
https://www.postgresql.org/message-id/cab7npqrdan1a1ynjxnl9t1juewct8ttqq29dnv
76 matches
Mail list logo
