Hi,
pg_itoa, pg_ltoa and pg_lltoa all have access to the length of the
string that is produced in the function by way of the "len" variable.
These functions don't have a great deal of use in core, but it seems
that most callers do require the len but end up getting it via
strlen(). It seems we cou
On 2020-06-08 23:32, Andres Freund wrote:
On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
If we can allow wal_level to be changed on the fly, I agree that would
help reduce the pressure to make the default setting more expensive.
I don't recall why it's PGC_POSTMASTER right now, but I suppose ther
On 2020/05/12 19:24, Andrey Lepikhov wrote:
Rebased onto current master (fb544735f1).
Thanks for the patches!
These patches are no longer applied cleanly and caused the compilation failure.
So could you rebase and update them?
The patches seem not to be registered in CommitFest yet.
Are yo
On Tue, 9 Jun 2020 at 15:11, Michael Paquier wrote:
>
> On Mon, Jun 08, 2020 at 05:44:56PM +0900, Kyotaro Horiguchi wrote:
> > Mmm. Right.
>
> Yep. I bumped on that myself. I am not sure about 0002 and 0004 yet,
> and IMO they are not mandatory pieces, but from what I can see in the
> set 0001 a
Hi,
On 2020-06-09 02:03:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Unfortunately it turns out that our CFLAG configure tests don't reliably
> > work with -Wold-style-definition. The problem is that the generated
> > program contains 'int main() {...}', which obviously is an old-style
>
On Mon, Jun 08, 2020 at 05:44:56PM +0900, Kyotaro Horiguchi wrote:
> Mmm. Right.
Yep. I bumped on that myself. I am not sure about 0002 and 0004 yet,
and IMO they are not mandatory pieces, but from what I can see in the
set 0001 and 0003 can just be squashed together to remove those
superuser ch
Hello, Euler.
At Mon, 8 Jun 2020 07:51:18 -0300, Euler Taveira
wrote in
> On Mon, 8 Jun 2020 at 05:27, Kyotaro Horiguchi
> wrote:
>
> >
> > That can be fixed by calling ProcessCompletedNotifies() in
> > apply_handle_commit. The function has a code to write out
> > notifications to connected c
On 2020-06-05 17:19:26 -0700, Andres Freund wrote:
> Hi,
>
> On 2020-06-04 19:33:02 -0700, Andres Freund wrote:
> > But it looks like that code is currently buggy (and looks like it always
> > has been), because we don't look at the nested argument when
> > initializing the semaphore. So we curren
Andres Freund writes:
> Unfortunately it turns out that our CFLAG configure tests don't reliably
> work with -Wold-style-definition. The problem is that the generated
> program contains 'int main() {...}', which obviously is an old-style
> definition. Which then causes a warning, which in turn cau
On Mon, Jun 8, 2020 at 10:16 PM Ashutosh Bapat
wrote:
> I know one project where they used PostgreSQL code base to detect
> "robust plans". https://dsl.cds.iisc.ac.in/projects/PICASSO/. Some of
> the papers cited in https://www.vldb.org/pvldb/vldb2010/papers/D01.pdf
> describe the idea.
>
In sh
Hi,
On 2020-05-09 19:11:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-05-09 14:15:01 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Since gcc has a warning detecting such definition, I think we ought to
> >>> automatically add it when available?
>
> >> +1
>
> > Any opi
I wrote:
> I'm trying to reproduce this now, but it's sounding pretty plausible.
Yeah, that's definitely it. I was able to reproduce the failure semi
reliably (every two or three tries) after adding -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE and inserting a "pg_sleep(1)" just after the
man
On Fri, Jun 5, 2020 at 2:30 PM Pavel Stehule
wrote:
>
>
> pá 5. 6. 2020 v 8:19 odesílatel David Rowley
> napsal:
>
>> On Mon, 1 Jun 2020 at 01:24, Andy Fan wrote:
>> > The one-line fix describe the exact idea in my mind:
>> >
>> > +++ b/src/backend/optimizer/path/costsize.c
>> > @@ -730,6 +730,
David Rowley writes:
> On Tue, 9 Jun 2020 at 15:41, Tom Lane wrote:
>> Hmm ... that's a plausible theory, perhaps. I forget: does autovac
>> recheck, after acquiring the requisite table lock, whether the table
>> still needs to be processed?
> It does, but I wondered if there was a window after
On Tue, 9 Jun 2020 at 15:41, Tom Lane wrote:
>
> David Rowley writes:
> > It does seem plausible, given how slow prion is that autovacuum might
> > be trigger after the manual vacuum somehow and building stats with
> > just 1k buckets instead of 10k.
>
> Hmm ... that's a plausible theory, perhaps
David Rowley writes:
> I see 0c882e52a did change the number of statistics targets on that
> table. The first failure was on the commit directly after that one.
> I'm not sure what instability Tom meant when he wrote "-- results
> below depend on having quite accurate stats for atest12".
See [1],
Andres Freund writes:
> And done.
LGTM, thanks!
regards, tom lane
On Tue, 9 Jun 2020 at 14:27, Thomas Munro wrote:
> Two recent failures show plan changes in RLS queries on master. Based
> on nearby comments, the choice plan is being used to verify access (or
> lack of access) to row estimates, so I guess that means something
> could be amiss here. (Or it coul
Hi,
On 2020-06-08 18:21:06 -0400, Tom Lane wrote:
> > Yea, it could just do that. It seemed slightly easier/clearer, back when
> > I wrote it, to just use pg_atomic_write* for the initialization, but
> > this seems enough of a reason to stop doing so. Will change it in all
> > branches, unless som
Thomas Munro writes:
> Two recent failures show plan changes in RLS queries on master.
Yeah. I assume this is related to 0c882e52a, but I'm not sure how.
The fact that we've only seen it on prion (which runs
-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE) is suggestive,
but it's not clear why
On Mon, Jun 08, 2020 at 02:16:32PM +0300, Alexey Kondratov wrote:
> BTW, most of 'common' is a really common code with only four exceptions
> like logging.c, which is frontend-only. Is it there for historical
> reasons only or something else?"
>
> Personally, I would prefer that everything in the
On Thu, 12 Jan 2017 at 12:06, Michael Paquier
wrote:
> On Thu, Jan 12, 2017 at 9:53 AM, James Sewell
> wrote:
> > What is needed to support this is the ability to configure Px with
> something like:
> >
> > 1 (P1, P2, P3), 1 (D1, D2, D3)
> >
> > Would there be any appetite for this - or would i
On Mon, Jun 08, 2020 at 05:50:44PM +1200, Thomas Munro wrote:
> On Fri, Jun 5, 2020 at 8:14 PM Michael Paquier wrote:\
>> Anyway, why are we sure that it is fine to not complain even if
>> BufFileWrite() does a partial write? fwrite() is mentioned at the
>> top
>> of the thread, but why is that O
Hello,
Two recent failures show plan changes in RLS queries on master. Based
on nearby comments, the choice plan is being used to verify access (or
lack of access) to row estimates, so I guess that means something
could be amiss here. (Or it could be due to the dropped UDP flaky
stats problem, b
On Tue, Jun 9, 2020 at 2:49 AM Alvaro Herrera wrote:
> I think using our standard "exception" mechanism makes sense. As for
> additional context, I think usefulness of the error messages would be
> improved by showing the file path (because then user knows which
> filesystem/tablespace was full,
Andres Freund writes:
> We currently have
> *bool SpinLockFree(slock_t *lock)
> *Tests if the lock is free. Returns true if free, false if
> locked.
> *This does *not* change the state of the lock.
> [ which isn't used ]
> Thus: Let's just remove SpinLockFree() / S_
Hi,
We currently have
* bool SpinLockFree(slock_t *lock)
* Tests if the lock is free. Returns true if free, false if
locked.
* This does *not* change the state of the lock.
and its underlying S_LOCK_FREE() operation:
*
* bool S_LOCK_FREE(slock_t *lock)
*
On Tue, Jun 9, 2020 at 4:13 AM Odin Ugedal wrote:
> This adds support for using non-default huge page sizes for shared
> memory. This is achived via the new "huge_page_size" config entry.
> The config value defaults to 0, meaning it will use the system default.
> ---
>
> This would be very helpful
Andres Freund writes:
> On 2020-06-07 00:23:35 -0400, Tom Lane wrote:
>> so my first thought was that we just needed an architecture-specific
>> variant of that. But on thinking more about this, it seems like
>> generic.h's version of pg_atomic_init_u64_impl is just fundamentally
>> misguided. W
Hi,
On 2020-06-07 00:23:35 -0400, Tom Lane wrote:
> I experimented with running "make check" on ARM64 under a reasonably
> bleeding-edge valgrind (3.16.0). One thing I ran into is that
> regress.c's test_atomic_ops fails; valgrind shows the stack trace
>
>fun:__aarch64_cas8_acq_rel
>fun:
Hi,
On 2020-06-08 13:27:50 -0400, Tom Lane wrote:
> If we can allow wal_level to be changed on the fly, I agree that would
> help reduce the pressure to make the default setting more expensive.
> I don't recall why it's PGC_POSTMASTER right now, but I suppose there
> was a reason for that ...
The
On Mon, Jun 08, 2020 at 07:18:49PM +0200, Pavel Stehule wrote:
> pá 29. 5. 2020 v 20:25 odesílatel Justin Pryzby napsal:
>
> > On Fri, May 29, 2020 at 04:21:00PM +0200, Pavel Stehule wrote:
> > > one my customer has to specify dumped tables name by name. After years and
> > > increasing database
Hi,
On 2020-06-08 14:58:03 -0400, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes essentiall
Hi,
On 2020-06-08 13:41:29 -0700, Jeff Davis wrote:
> On Fri, 2020-06-05 at 21:11 -0700, Andres Freund wrote:
> > Before there was basically one call from nodeAgg.c to execGrouping.c
> > for
> > each tuple and hash table. Now it's a lot more complicated:
> > 1) nodeAgg.c: prepare_hash_slot()
> > 2
On Fri, 2020-06-05 at 21:11 -0700, Andres Freund wrote:
> Why isn't the flow more like this:
> 1) prepare_hash_slot()
> 2) if (aggstate->hash_spill_mode) goto 3; else goto 4
> 3) entry = LookupTupleHashEntry(&hash); if (!entry)
> hashagg_spill_tuple();
> 4) InsertTupleHashEntry(&hash, &isnew); if (
On 2020-06-08 17:19, Tom Lane wrote:
Daniel Gustafsson writes:
On 8 Jun 2020, at 16:33, Tom Lane wrote:
Hm, I don't see any documentation change in that commit --- don't
we have (at least) a list of the stemmers somewhere in the SGML docs?
IIRC we refer to the Snowball site, and only have
On Fri, 2020-06-05 at 21:11 -0700, Andres Freund wrote:
> Before there was basically one call from nodeAgg.c to execGrouping.c
> for
> each tuple and hash table. Now it's a lot more complicated:
> 1) nodeAgg.c: prepare_hash_slot()
> 2) execGrouping.c: TupleHashTableHash()
> 3) nodeAgg.c: lookup_has
On Mon, Jun 8, 2020 at 12:28 PM Alvaro Herrera wrote:
> On a quantum-mechanics level, sure, but after Andres's snapshot
> scalability patches, will it be measurable? (Besides, if your workload
> is so high that you're measurably affected by the additional unused
> PGPROC entries, you can always t
On 2020-Jun-05, Andres Freund wrote:
> While preparing my pgcon talk I noticed that our hash-agg performance
> degraded noticeably. Looks to me like it's due to the spilling-hashagg
> changes.
Jeff, what are your thoughts on this?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Po
On 2020-Jun-08, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes essentially no resources; an
On Mon, Jun 8, 2020 at 12:09 PM Robert Haas wrote:
> I think the big overhead is that you log the old version of each row's
> primary key (or whatever the replica identity is) when performing an
> UPDATE or DELETE. So if you test it with integer keys probably it's
> not bad, and I suspect (though
On Mon, Jun 8, 2020 at 5:11 AM Magnus Hagander wrote:
> I agree that we should consider changing it *if* it does not come with a
> substantial overhead, but that has to be shown.
I think the big overhead is that you log the old version of each row's
primary key (or whatever the replica identity
On Mon, Jun 08, 2020 at 02:58:03PM -0400, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera
> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100). An unused slot wastes ess
On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera wrote:
> I think it's reasonable to push our default limits for slots,
> walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> 100). An unused slot wastes essentially no resources; an unused
> walsender is just one PGPROC entry.
Alvaro Herrera writes:
> I think it's reasonable to push our default limits for slots,
> walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> 100). An unused slot wastes essentially no resources; an unused
> walsender is just one PGPROC entry. If we did that, and also allow
Hi
pá 29. 5. 2020 v 20:25 odesílatel Justin Pryzby
napsal:
> On Fri, May 29, 2020 at 04:21:00PM +0200, Pavel Stehule wrote:
> > one my customer has to specify dumped tables name by name. After years
> and
> > increasing database size and table numbers he has problem with too short
> > command li
On 2020-Jun-08, Tomas Vondra wrote:
> Not sure if it's sufficient, though, because switching to logical may
> require bumping up number of slots, walsenders, etc. At which point you
> actually need a restart. Not to mention that extensions using logical
> decoding (like pglogical) need to allocate
On 2020-Jun-03, Amit Langote wrote:
> Are you saying that the planner should take into account the state of
> the cursor specified in WHERE CURRENT OF to determine which of the
> tables to scan for the UPDATE? Note that neither partition pruning
> nor constraint exclusion know that CurrentOfExpr
On 2020-Jun-08, Anastasia Lubennikova wrote:
> In this version I rebased test patches, added some more comments, fixed
> memory allocation issue and also removed code that handles ACLs on
> languages. They require a lot of specific handling, while I doubt that their
> signatures, which consist of
On 2020-Jun-08, Justin Pryzby wrote:
> On Mon, Jun 08, 2020 at 11:27:26AM -0400, Alvaro Herrera wrote:
> > Well, that would also require that transactions are committed and
> > started for each partition. Merely adding PreventInTransactionBlock
> > would not do that. Moreover, since this would
On Mon, Jun 08, 2020 at 11:10:38AM +0200, Magnus Hagander wrote:
> On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
>
> > On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> > > I think we should first do performance testing to see what is the
> > > overhead of making this default
This adds support for using non-default huge page sizes for shared
memory. This is achived via the new "huge_page_size" config entry.
The config value defaults to 0, meaning it will use the system default.
---
This would be very helpful when running in kubernetes since nodes may
support multiple h
On 06.04.2020 19:40, Anastasia Lubennikova wrote:
On 06.04.2020 16:49, Anastasia Lubennikova wrote:
New version of the patch is attached. I fixed several issues in the
check_for_changed_signatures().
Now it passes check without "test_rename_catalog_objects" and fails
(generates script) with i
On Mon, Jun 08, 2020 at 11:27:26AM -0400, Alvaro Herrera wrote:
> On 2020-Jun-08, Justin Pryzby wrote:
>
> > This blocks writes to all partitions until commit:
> >
> > postgres=# begin; CREATE INDEX ON pt(i);
> > BEGIN
> > CREATE INDEX
> >
> > Compare with CLUSTER rel1, rel2, ..., and REINDEX {S
On 2020-Jun-08, Justin Pryzby wrote:
> This blocks writes to all partitions until commit:
>
> postgres=# begin; CREATE INDEX ON pt(i);
> BEGIN
> CREATE INDEX
>
> Compare with CLUSTER rel1, rel2, ..., and REINDEX {SCHEMA|DATABASE|SYSTEM},
> which release their locks as soon as each rel is process
Daniel Gustafsson writes:
> On 8 Jun 2020, at 16:33, Tom Lane wrote:
>> Hm, I don't see any documentation change in that commit --- don't
>> we have (at least) a list of the stemmers somewhere in the SGML docs?
> IIRC we refer to the Snowball site, and only have a list in the \dFd output,
> but
On 2020-Jun-08, Thomas Munro wrote:
> Stepping back a bit, one of the problems here is that we tried to
> model the functions on fread(), but we didn't provide the
> companion ferror() and feof() functions, and then we were a bit fuzzy
> on when errno is set, even though the functions don't
> do
> On 8 Jun 2020, at 16:33, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 2020-05-22 14:40, Peter Eisentraut wrote:
>>> I think some consideration could be given for including this into PG13.
>>> Otherwise, I'll park it for PG14.
>
>> committed to master
>
> Hm, I don't see any documentati
Peter Eisentraut writes:
> On 2020-05-22 14:40, Peter Eisentraut wrote:
>> I think some consideration could be given for including this into PG13.
>> Otherwise, I'll park it for PG14.
> committed to master
Hm, I don't see any documentation change in that commit --- don't
we have (at least) a lis
On Tue, 2 Jun 2020 at 03:13, David Rowley wrote:
>
>
> It does seem likely to me that hash tables would be a more efficient
> structure, but the gains might not be as big as you think. To perform
> a lookup in the table we need to hash the entire node to get the hash
> value, then perform at leas
I know one project where they used PostgreSQL code base to detect
"robust plans". https://dsl.cds.iisc.ac.in/projects/PICASSO/. Some of
the papers cited in https://www.vldb.org/pvldb/vldb2010/papers/D01.pdf
describe the idea.
In short, the idea is to annotate a plan with a "bandwidth" i.e. how
doe
Peter Eisentraut writes:
> On 2020-06-07 17:00, Tom Lane wrote:
>> Relevant to the current discussion: this creates a possible positive
>> reason for setting dynamic_shared_memory_type to "sysv", namely if it's
>> the best available way to get around RemoveIPC in a particular situation.
>> Should
On Mon, Jun 08, 2020 at 11:10:38AM +0200, Magnus Hagander wrote:
On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> I think we should first do performance testing to see what is the
> overhead of making this default. I think pg
On Mon, Jun 1, 2020 at 8:35 PM Tom Lane wrote:
>
> Kenichiro Tanaka writes:
> > I think table column width of UNION statement should be equal one of UNION
> > ALL.
>
> I don't buy that argument, because there could be type coercions involved,
> so that the result width isn't necessarily equal t
The tests
src/bin/pg_basebackup/t/010_pg_basebackup.pl
src/bin/pg_rewind/t/004_pg_xlog_symlink.pl
both contain a TAP skip notice "symlinks not supported on Windows".
This is untrue. Symlinks certainly work on Windows, and we have other
TAP tests using them, for example for tablespaces.
pg_r
On 2020-06-04 17:04, Atsushi Torikoshi wrote:
On Mon, May 25, 2020 at 10:54 AM Atsushi Torikoshi
wrote:
On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi
wrote:
Cost numbers would look better if it is cooked a bit. Is it worth
being in core?
I didn't come up with ideas about how to use t
po 8. 6. 2020 v 13:40 odesílatel Asif Rehman
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:tested, passed
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
The patch applies cleanly and AFAICS there are no issues with the
On 2020-06-08 09:14, Michael Paquier wrote:
On Sun, Jun 07, 2020 at 10:05:03PM +0300, Alexander Korotkov wrote:
On Sat, Jun 6, 2020 at 8:49 PM Peter Eisentraut
wrote:
Why is fe_archive.c in src/common/ and not in src/fe_utils/? It is
not
"common" to frontend and backend.
Yep, this seems wr
On Mon, 8 Jun 2020 at 05:27, Kyotaro Horiguchi
wrote:
>
> That can be fixed by calling ProcessCompletedNotifies() in
> apply_handle_commit. The function has a code to write out
> notifications to connected clients but it doesn't nothing on logical
> replication workers.
>
>
This bug was already r
On Fri, May 29, 2020 at 12:54 PM Fujii Masao
wrote:
>
>
> On 2020/05/27 16:10, Michael Paquier wrote:
> > On Tue, May 26, 2020 at 07:30:54PM +, Bossart, Nathan wrote:
> >> While an assertion in UpdateControlFile() would not have helped us
> >> catch the problem I initially reported, it does s
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
This small documentation patch makes the document more accurate for p
This blocks writes to all partitions until commit:
postgres=# begin; CREATE INDEX ON pt(i);
BEGIN
CREATE INDEX
Compare with CLUSTER rel1, rel2, ..., and REINDEX {SCHEMA|DATABASE|SYSTEM},
which release their locks as soon as each rel is processed.
I noticed while implementing REINDEX for partitio
Hi Kyotaro Horiguchi, thanks for you helps.
We have a question about the bug. Why there isn't any solution in the HEAD?
This bug last since 10.4 version and I can't understand why it is not fixed in
the HEAD yet.
BR.
Fabio Vianello.
-Original Message-
From: Kyotaro Horiguchi [mailto:h
On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier wrote:
> On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> > I think we should first do performance testing to see what is the
> > overhead of making this default. I think pgbench read-write at
> > various scale factors would be a good
At Mon, 8 Jun 2020 16:21:45 +0900, Masahiko Sawada
wrote in
> I've looked at these patches and have one question:
>
> REVOKE ALL ON pg_replication_origin_status FROM public;
>
> +GRANT SELECT ON pg_replication_origin_status TO pg_read_all_stats;
>
> +REVOKE EXECUTE ON FUNCTION pg_show_replic
Hello.
It seems to me a bug.
At Fri, 05 Jun 2020 11:05:14 +, PG Bug reporting form
wrote in
> The following bug has been logged on the website:
>
> Bug reference: 16481
> Logged by: Fabio Vianello
> Email address: fabio.viane...@salvagninigroup.com
> PostgreSQL version:
Hello, Martín.
Thanks for the new version.
At Thu, 4 Jun 2020 09:17:18 -0300, Martín Marqués
wrote in
> > I'm not sure where to put the GRANT on
> > pg_show_replication_origin_status(), but maybe it also should be at
> > the same place.
>
> Yes, I agree that it makes the revoking/granting eas
On Thu, 4 Jun 2020 at 21:17, Martín Marqués wrote:
>
> Hi Kyotaro-san,
>
> > Sorry for not mentioning it at that time, but about the following diff:
> >
> > +GRANT SELECT ON pg_replication_origin_status TO pg_read_all_stats;
> >
> > system_views.sql already has a REVOKE command on the view. We sho
On Sun, Jun 07, 2020 at 11:06:27AM -0400, Tom Lane wrote:
> The maintainer says he'll revert the change, so I suppose the
> buildfarm will go back to normal without extra effort on our part.
The buildfarm has moved back to a green state as of the moment I am
writing this email (see serinus for exa
80 matches
Mail list logo
